制約っていらなくね？

1 ：NAME IS NULL：04/06/17 23:49 ID:fs3qldjg

プログラム側で制御しろよ

48 ：43：04/07/21 18:53 ID:???

>>45
あたくしの場合、火消し役やらされてる間も
他の案件の保守で人月工数出とるんで
コストかかっとらんのですわ。

だから便利に使われるって訳です。疲れた・・・・。

49 ：NAME IS NULL：04/07/21 19:32 ID:???

納期間に合わなさそう
↓
新しい人材を大量投入
↓
スキル高い人の手間が、新しい人への引継や教育に取られる
↓
さらに炎上


こういうパターンが多いよな。

50 ：NAME IS NULL：04/12/01 18:41:41 ID:???

うちでは、主キー以外の制約はってません
それはＩＳＡＭ的なんでしょうか？
なんかＤＢＭＳの機能を使ってるきがしない
関連削除も不具合が発見されてから、整合性調整アプリを作ってるし
みんなはきちんと関連図みたいなんカタメテからやってるんですよね？

51 ：NAME IS NULL：04/12/02 18:05:14 ID:???

実はうちもです。
カスケードってなーに？

頑張ってアプリ側で実装ですよ。

52 ：NAME IS NULL：04/12/15 07:00:38 ID:6kA6XGLm

このスレっていらなくね？

53 ：NAME IS NULL：04/12/15 23:47:32 ID:???

あとから設計見てどういう意図で組んだのかわかりやすいから制約は付けてるなあ
どーせ突っ込む前にデータチェックするんだけどね

54 ：NAME IS NULL：05/01/04 23:49:35 ID:gtuR+WFj

制約かぁ・・・

参照性合成制約とかトリガーによるチェックはどうかと思うが、
主キーとNOT NULL制約は最低限付けた方が良いな。

55 ：NAME IS NULL：2005/03/29(火) 17:51:13 ID:???

1 WEBからデータ入力（クライアントでのデータチェック）
2 サーバプログラムで加工（サーバでのデータチェック）
3 DBに格納（DBMSでのデータチェック）

なんかもどかしい.

56 ：NAME IS NULL：2005/07/27(水) 11:06:36 ID:rghdAW4Q

保守する時に、
参照整合性制約サイコー。
トリガーは糞。

と思う事が多いのだが、
どうか？

57 ：NAME IS NULL：2005/07/27(水) 13:59:40 ID:???

>>56
参照整合制約って使った事ないけど
保守する上でどうサイコー？
本で読むような利点じゃなくて
現場の濃い話希望。

58 ：NAME IS NULL：2005/07/28(木) 10:46:45 ID:KXoQY93/

売春婦（DB）とその客（アプリ）に例えれば･･･。
入れるときに相手にゴムの着用を求めても、それが万全とはいえないし、そもそもつけるかも強制できない。
そうであれば、自分で制約（避妊手段）を準備しておくのが、変なデータを作らないための予防策。

59 ：NAME IS NULL：2005/07/28(木) 18:55:51 ID:???

>>57
56じゃないが俺はゴミが入らないのが利点だと思う。
これ以上でもこれ以下でもない。
ありえないデータが入ってるDBなんざみたくねぇ！！

トリガーは便利だと思うけどな。
そのありえないデータを削除したりするのによく使う。

60 ：NAME IS NULL：2005/07/28(木) 23:56:28 ID:???

トリガーって、ER図から読み取れないから怖いやね。
時刻更新とか、極簡単で引継ぎしやすい物であれば便利だと思う。

スパープログラマな人が、作ったｵﾚｻﾏﾄﾘｶﾞｰは、簡便∩( ・ω・)∩

61 ：NAME IS NULL：2005/07/29(金) 00:17:42 ID:???

参照整合性制約を張るとインデックスが張られるやね。
そのＥＲ図をプログラマに配っておけば、自然とコチラの意図通りの
インデックスを使ったＳＱＬを書いてくれるといいなぁ。。。
（そこそこのレベルの人なら分かってくれる。）

他には、
・参照整合性制約に基づいた連鎖更新・削除が便利。

・Access2003のXMLエクスポート機能を使う場合に
　参照整合性制約に基づいて親子テーブルを
　エクスポート出来るとか。

中小規模で、レスポンス性能とかシビアでなければ
参照整合性制約付けといた方が管理しやすいと思う。

問題になれば、外すだけで性能アップさせましたと
言えるかもしれないし。。(￣ー￣)ﾆﾔﾘ

62 ：NAME IS NULL：2005/07/29(金) 00:18:49 ID:???

現場の濃い話って、↓こんなのか？

中小SI　ﾍｯﾎﾟｺｼｽﾃﾑ
客「このデータ消したいなぁ」
担「何度も申し上げた通り（略」
客「前の担当者なら（略」
上司「ﾔﾚ!」
担「しかしDBを直接弄るのは、（略」
上司「この辺のﾃﾞｰﾀを（略」
担「...」
客「ﾃﾞｰﾀがｵｶｼｲｿﾞ（略」
上司「誰がそんな事をﾔﾚと（略」
担「...」

63 ：NAME IS NULL：2005/07/29(金) 12:22:38 ID:???

>>59
ゴミの排除を制約に全部まかせちゃうんですか？
恐いなーと思って。

何がゴミかとかありえないデータかってのは
業務要件だったりする事が多いわけで
それはアプリ側で実装されてた方がわかり易いし
管理も楽だと思うんですよ。

で、制約をつけると、再実装になるし
保守も難儀な事になりそう。

そうでもないのかな？

64 ：63：2005/07/29(金) 12:27:28 ID:???

あ、煽ってる訳じゃないです。
制約に対する偏見なのかなあって
ちょっと思ってきては居るんで
背中押してもらいたいというのが本音。

>61の連鎖削除・更新も
業務要件だからアプリで実装したいんですよねぇ。
トリガーもそうなんですが。

ださいのかなー。

あっ、でもレスポンス向上の一手に使えるってのは
いいっすね！そういうかわいい悪どさは好きです。

65 ：NAME IS NULL：2005/07/29(金) 13:13:32 ID:ug+wSNY+

>>63-64
直接引用じゃなく、要点絞って記述するね。

>アプリで実装するほうが判りやすくて楽
１つのテーブルに対する処理が10個も20個もあるアプリで、
全ての処理が正しく動作することを補償するのは楽でしょうか？
NOT NULLの制約もないDBとか最悪ですよ。

>制約をつけると再実装
逆です、制約がまず実装でアプリ側が再実装。
アプリ作るのに、DB設計もせずに始めるのでしょうか？

で、トリガーと制約は別問題。
論理的制約をトリガーで実装するってのはあるけど。

主キーもない、NULL制約もないDBなんて、DB使わないでファイルに書けばいいじゃん。ｗ

66 ：NAME IS NULL：2005/07/29(金) 13:48:36 ID:ZZgow+OE

火と大杉で見れないよ

67 ：63：2005/07/29(金) 14:08:49 ID:???

>>65
まず具体的にNOT NULL制約に話なんですが、
業務要件としてNOT NULLなものって
アプリ側で入力チェックしますよね。
アプリ側の実装はどうしても必要になっちゃう。
で、そういうチェックはユーティリティクラスとかヴァリデーターとか
そんな風に共通化する訳です。

1つのテーブルに対して10個も20個も処理があったとして
アプリ側の設計で実装は1つにまとめられると思います。

で、ままあるんですが、当初NOT NULLだと思ってたのが
実はNULLもあるんだよーなんて突然お客様に言われた時に
アプリ側で仕様が把握し切れればいいんじゃないかなと思っちゃう。

>アプリ作るのに、DB設計もせずに始めるのでしょうか？
DB設計は事前にしますよ。ER図も書きます。
でもそれは論理設計と言うか概念設計です。
実際にDBを構える時はまた考え直します。

概念設計において業務要件を反映した制約を
そのまま実装としてDBに入れるか、
アプリでやるかって所だと。

ちょっと話はずれますが、
概念設計と実装で構成が違うのは当たり前にやってます。
特に識別子の考え方。概念では識別子は業務に沿って考えます。
だから「注文番号 + 行番」なんて複合キーもガンガン使います。
でも実装では、「注文明細ID」をキーにします。
勿論、一意制約とインデックスは「注文番号 + 行番」につけますけど。

だから、参照整合やNOT NULLに関しても
実装ではぶいてアプリで実装ってのにあまり抵抗がないのかも
知れません。

うーん、書いてて自分の強い優位性が見出せぬ。
過去の振り返りにしかなってない・・・わはは。

レス有難う御座います。長文失敬でした。

68 ：NAME IS NULL：2005/07/29(金) 14:33:29 ID:ug+wSNY+

>>67
> 業務要件としてNOT NULLなものって
> アプリ側で入力チェックしますよね。
> アプリ側の実装はどうしても必要になっちゃう。
> で、そういうチェックはユーティリティクラスとかヴァリデーターとか
> そんな風に共通化する訳です。

アプリでの入力チェックとNotNull制約では、後者のほうが広い意味です。
入力チェックしても防げないバグデータでも制約で防げます。
それに、アプリを通さないDBテーブル同士でのデータ登録とか更新もありますし。

> 1つのテーブルに対して10個も20個も処理があったとして
> アプリ側の設計で実装は1つにまとめられると思います。

クラスなど実装が１つにまとめられることと、SQLの種類が複数になることは別問題ですよ。
その各パターン毎の更新などに対して、不慮の事故などをどのようの防ぐのですか？
全てのパターンを１つの汎用SQLで行った場合にしても、それらのパターン毎の試験は必要です。

> 概念設計において業務要件を反映した制約を
> そのまま実装としてDBに入れるか、
> アプリでやるかって所だと。

DBの責務としての制約はDBでやるべきだし、アプリの制約はアプリでやるべき。
それに、DBが常にアプリを通して更新されるとは限らないし。
メンテとか、後の修正や他システムとの連携などで、そのアプリに対する制約を相手に望めますか？

> うーん、書いてて自分の強い優位性が見出せぬ。
> 過去の振り返りにしかなってない・・・わはは。

だって、便利な機能を否定して茨の道を歩んでるから。
両方制約すればいいんですよ、DBとアプリの独立性を高めて考えて、それぞれの責務を課す。
DBは自分の入れられたくないデータを制約し、アプリは他に出せないデータは出さない。

69 ：63：2005/07/29(金) 15:35:16 ID:???

>>68
うーむ、茨の道、耳が痛いです。
やっぱりやった事ないから恐いってだけなんでしょうかね。
有難う御座います。

確かに、アプリを経由しないデータ連携などではお手上げですね。
最初からそんな要件なければいいですが
案件ごとに制約の実装方法がDB or アプリで
バラバラになっちゃうのも気持ち悪いですし
ポリシーとして最初から統一しちゃう方が、確かに安心。

あと、DBからの制約のエラーと
アプリでのエラーメッセージのマッピングで
困った事とかないですか？
DBからのエラーコードじゃ判りきらんよ、とか。
それも気になる所なのです。

柔軟にメッセージを対応させたきゃそれこそアプリの責務で、
アプリ側でチェックすれって所でしょうか。

70 ：NAME IS NULL：2005/07/29(金) 15:52:26 ID:6uLcICyZ

DBから見たら制約を課すことまでが責務であって、その結果を返すだけだよ。
そのエラーをアプリがどう料理するかはアプリの実装の問題。
特定のエラーコードに意味を求める（キー重複など）場合はそのコードで分岐して処理すればいいし。
NULL制約違反ってのはあまり出したくはないよね。
やっぱ、アプリで事前チェックして、そもそもINSERTなどを投げないようにしたい。
Oracleとかだと、どのカラムで何のエラーってメッセージはもらえるけど、あくまで文字列情報だし、
貴方が悩むところはなんとなくは判ります。

そもそもとして、DBに制約をつけるのってそんなに大変か？ｗ
Check制約にしても、そんなに手間じゃないでしょ。

71 ：63：2005/07/29(金) 16:07:46 ID:???

おっしゃる通り、別に大変でもないですよね。わはは。

飛ぶのが恐いわけじゃない、落ちていくのが恐いんだ
by 寺山修司

って心境です。
派手にバグを出してデータパッチわんさか当てなきゃーとか
なった時に、参照整合とかで苦労しないかなーとか
勝手に妄想してるのです。

次は飛んでみるかな。

72 ：NAME IS NULL：2005/07/29(金) 16:21:06 ID:6uLcICyZ

>>71
想定してる場面が発生する原因は・・・。
1）システム分析が甘く、DB設計が間違っている為、実情に合わない制約をDBに課した
2）そもそもの業務がフレキシブル（ｗ、なので、その時点での制約が邪魔になる。
のどちらかだと思うが。

前者であれば技量を磨くしかないし、後者はそもそも制約を付与する設計がやっぱり間違っているともいえる。
制約って基本的にはきつく課しておいて、緩めるときに本当に緩める理由があるか考えるほうが安全だよ。

73 ：NAME IS NULL：2005/07/29(金) 23:47:30 ID:???

>>64
連鎖削除・更新は、注文-注文明細とかで考えると、
業務要件では無くＲＤＢ側の物理実装時の都合だと思う。

と、言いつつも管理が面倒なので、アプリ側に実装させて
自分がＤＢを直接弄る場合にのみ、一時的に有効にするのが
ｵﾚｻﾏのやり方だな。

74 ：NAME IS NULL：2005/07/29(金) 23:56:57 ID:???

NOT NULLの制約については、文字型について
Oracleと、SQLServerで扱いが微妙に違うのがイタイな。
Oracleは、NullとEmptyの違いが無いのに対して
SQLServerは、NullとEmptyを明確に区別する。

そのため、ほとんどのフィールドは、Nullを許可しているな。

考え方は、SQLServerの方が好きだな。
他の、DBってどうなのだろう。。？

75 ：NAME IS NULL：2005/07/30(土) 00:17:52 ID:???

さんざん書かれているけど、基本的な考えとしてアプリケーションありきの
モデリングを行うのは、後々の拡張性とか考えると嫌だな。

↓ちょうど良い記事を見つけた。
データは安定している 〜POAからDOAへ
ttp://pcweb.mycom.co.jp/series/stratesys/010/

所で、
制約の管理とか、モデリングツールにより
かなり効率が違ってくると思うのですが、
何かつかってます？

漏れの場合は、Erwin3.5使ってて
最近は値段の関係から、ER/Studioに移行させられそう。。。

76 ：NAME IS NULL：2005/07/30(土) 00:31:04 ID:???

うちはOBERです。
そーんなに使い勝手いいとは思えないかな・・・。

77 ：NAME IS NULL：2005/07/30(土) 06:07:29 ID:???

チラシの裏最強！

78 ：NAME IS NULL：2005/07/30(土) 09:53:03 ID:???

>>77
どの辺がチラシと思った？

79 ：NAME IS NULL：2005/07/30(土) 22:52:42 ID:???

>>74
DB2もPostgreも区別するよ。
つーかOracleが特殊なだけな気がする。

80 ：NAME IS NULL：2005/07/31(日) 02:33:05 ID:???

>>78
日記の裏でなくて
モデリングツールなぞ
チラシの裏で十分です
って話でそ。

81 ：NAME IS NULL：2005/07/31(日) 03:00:10 ID:???

>>80
そういう意味か。。

制約の保守が〜、といった話が出ていたので、
その流れのつもりだったんだけどな。

漏れは、Erwin様にＤＤＬだとか、管理してもらっているので、
モデリングツール無くなると、作業効率がた落ちなんだな。
ＤＢ自体と物理モデルの完全比較とか、使いこなすまでが
大変だけ使いこなすとスコブル便利だよ。

もう、手動で管理する自信ありませんぜ。

82 ：NAME IS NULL：2005/07/31(日) 03:03:30 ID:???

>>79
なるほどね。
ｻﾝｸｽ!

83 ：NAME IS NULL：2005/08/01(月) 05:30:05 ID:???

>>81
モデリングツールは設計ツールじゃなくて保守ツールと考えると納得いく。
設計は紙と鉛筆が基本だけど、後のことを考えてあえて手間ひまかけてツールを使う。
だから保守をやらない開発メンバーには評判が悪かったりする。

84 ：NAME IS NULL：2005/08/01(月) 10:31:03 ID:???

そうなのか、評判悪いのか。。

漏れは中小規模な案件が多いせいか、
引き継ぎと言う事例が少ないだけで（~-~;
しょうがなしに保守や改善対応している
開発よりのタイプなんだけどな。

そういえば、UMLっぽい物をVisioで
書こうとした時はﾒﾝﾄﾞｸｾと思った。
あんな感じなのかな。

85 ：NAME IS NULL：2005/08/01(月) 10:48:40 ID:???

「保守を行わない開発メンバー」という
箇所を見落としてた。

とはいえ、統一したフォーマットの
DDL書いてくれるだけでも便利だと
思うのだけどな。

そういった観点か既に保守する立場と（略

86 ：NAME IS NULL：2005/08/01(月) 12:08:59 ID:???

チラシの裏書いた本人だが、終盤はモデルツールでやりますよ。
ただ、概念から順次ツールに合わせて落としていくっていうのがどうも制限になって嫌で。
手法の１つとしてはツールの手順でもいいけど、設計ってそこまで理想的に出来ないこと多いし。
とりあえずの概念設計とかはチラシの裏というか裏紙が一番いい。

87 ：NAME IS NULL：2005/08/01(月) 22:58:35 ID:???

そのままの意味だったとは。。。
そいつぁ　盲点だたよ　(^　^　;

88 ：NAME IS NULL：2006/06/08(木) 23:51:07 ID:???

ここで書き込んでいる人たちはずいぶん専門的な話題が多いようですが、
具体的にいったいどんな規模のどんなシステムに関わってるんでしょうか？？

ここでいう「中小」とはどれくらいのものを指すんだろう・・・。

89 ：NAME IS NULL：2006/06/30(金) 00:59:24 ID:???

中…1000万行程度、数十テーブル程度で同時接続ユーザ数100人程度
小…100万行程度、数テーブル以下で列数最大20-100列、同時接続ユーザ数数名程度

90 ：NAME IS NULL：2006/08/05(土) 00:40:54 ID:???

今やってるのは
100万行程度、数百テーブルで列数最大100列、同時接続ユーザ数数名程度
ですが・・・

91 ：NAME IS NULL：2006/08/15(火) 00:15:31 ID:???

>90
あまり細かい事を気にすると頭髪的にチャレンジされている方々の仲間入りしちゃうぞ。

92 ：NAME IS NULL：2006/08/17(木) 11:00:08 ID:???

きみは政治的に正しいやつだね

93 ：NAME IS NULL：2006/11/25(土) 01:59:26 ID:???

てｓｔ

94 ：NAME IS NULL：2007/03/18(日) 01:54:18 ID:???

プログラム側でわかりやすいエラーを出すのはもちろんだけど
制約があればプログラムがバグってても間違ったデータは入らないので
フェールセーフにはなるよね。プログラム側の制御はフールプルーフということで。
制約の付け方が間違ってたら設計者を死刑で。

95 ：NAME IS NULL：2007/10/27(土) 22:41:17 ID:???

制約は、Not Null、主キー、一意制約くらいいしか使わない

96 ：NAME IS NULL：2007/11/05(月) 01:17:42 ID:???

>>94
自分もそう思って、可能な限り設計通りに参照整合性制約とか実装してる。
最近はマシンの性能も追いついて来た感じがあるし、設計と実装の乖離が
なくなってイイ感じ。

97 ：NAME IS NULL：2008/06/21(土) 22:53:28 ID:???

保守してみるか