07/03/18 01:54:18 .net
プログラム側でわかりやすいエラーを出すのはもちろんだけど
制約があればプログラムがバグってても間違ったデータは入らないので
フェールセーフにはなるよね。プログラム側の制御はフールプルーフということで。
制約の付け方が間違ってたら設計者を死刑で。
95:NAME IS NULL
07/10/27 22:41:17 .net
制約は、Not Null、主キー、一意制約くらいいしか使わない
96:NAME IS NULL
07/11/05 01:17:42 .net
>>94
自分もそう思って、可能な限り設計通りに参照整合性制約とか実装してる。
最近はマシンの性能も追いついて来た感じがあるし、設計と実装の乖離が
なくなってイイ感じ。
97:NAME IS NULL
08/06/21 22:53:28 .net
保守してみるか
98:NAME IS NULL
09/01/03 00:07:53 3emwlJX+.net
>>74
確かに実装レベルでは、Oracleが特殊だが、SQL標準からすると、Oracleが正解。
でも、Oracle8とかOracle9のせいでOracle嫌いになってしまったけどね。
(バグが多いくせにパッチ当てるのも一苦労だし)
で、制約に関しては、参照整合性制約以外は、つけたほうがいいと思う。
参照整合性だけは微妙だと思うけどね。
でも、制約にすべてのエラーチェックを任せるのはいかがなものだと思うよ。
アプリ側でチェックして、最後の砦として、制約を使うのが正解だと思う。
昔みたアプリで、とりあえず、INSERTしてみて、エラーが出たら、制約違反です
とかの処理のがあったけど、言語道断だと思う。
後、デフォルト値(制約じゃないけど)も付けといてもいいと思う。
でも、デフォルト値に設定したいがために、INSERT文で指定しないってのは
言語道断だと思う。
99:NAME IS NULL
09/04/02 10:03:38 .net
言語道断・・げんごみちだん？
100:NAME IS NULL
09/04/03 21:37:01 .net
>>99
3ヶ月掛けて考えたレスがそれか・・・
101:NAME IS NULL
09/04/24 07:29:57 .net
>>99
げんごどうだん
102:NAME IS NULL
09/07/02 12:27:22 .net
保守ついでに。
ITアーキテクトの「やってはいけない」
［データベース設計編］参照整合性制約機能を多用してはいけない
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
はてブでは否定的なコメントが多いが、このスレの住人的にはどうなんだろ？
103:NAME IS NULL
09/07/03 18:04:26 .net
ストアドよりインデックスの方が速いよ。
104:NAME IS NULL
09/07/19 18:08:40 .net
データベースの目的によるんじゃないか
ただのストレージとしてなら、参照性合成制約なんか邪魔なだけ
モデルをあらわすものなら、制約付けとくほうがいいのかな
105:NAME IS NULL
09/07/19 22:31:04 .net
商品番号のくだり馬鹿かよ
106:NAME IS NULL
09/08/02 20:10:13 .net
>>102
「参照制約を多用してはいけない」とは思うけど、
それは主にレスポンスの問題だな
こいつの挙げてる理由はどうでもいい
・移行時に時間がかかる
→移行なんてそうそうやるもんじゃないし、別に時間かかってもいい
・マスタにないデータが登録できない
→それが正常だし、アプリで制約実装しても同じ問題が起こる
107:NAME IS NULL
09/08/02 20:47:06 .net
藤塚 勤也（ふじづか きんや）
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 エグゼクティブITスペシャリスト（データベース）
日頃はオリジナルOSSを中心に，技術開発やそのビジネス化に従事。
特にシステムの中核であるRDBMSには常に着目し，ITスペシャリストとして後進の指導にも注力している。
「RDBMS解剖学」（翔泳社）を共著。
データの人間ってこんなレベルのやつらばかりなのか？
こんなレベルで後進の指導に注力されてもこまるんだがｗ
108:NAME IS NULL
09/08/02 20:53:12 .net
基本丸投げで
109:名無しさん＠そうだ選挙に行こう
10/07/11 16:56:08 .net
データ社員が使えるとか何の笑い話だ？
110:NAME IS NULL
10/07/13 15:20:02 .net
> 通常業務処理の中でも問題になるケースがある。
> 例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。
ふむふむ。
> まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。
ああそうですか。
>仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。
まあそうですね。
>このような業務処理は実行できなくなってしまう。
えええ？
>仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。
はぁぁぁ？
お前が設計してはいけない。
111:
12/05/26 14:52:17.07 .net BE:486490368-PLT(12079)
せやな
112:NAME IS NULL
14/02/27 19:09:42.31 .net
>>102
>データを移行する際、先に受注テーブルを移行させようとすると
>参照整合性違反となり、RDBMSはエラーを返す。
>必ず、商品テーブルのデータ移行後に、
>受注テーブルのデータ移行を行わなければならない。
参照元-参照先という関係は半順序だからDAG(非循環有向グラフ)で表現できる
このDAGをトポロジカルソートすれば、
参照整合性違反にならないテーブルの移行順序を機械的に導出できる
これはグラフ・アルゴリズムの初歩的な応用だ(makeコマンドを知っていれば合点がつくと思う)
>仮受注のデータも受注テーブルで管理しようとしても、
>商品テーブルにない商品番号のデータは追加できない。
>このような業務処理は実行できなくなってしまう。
これは業務分析なりDB設計のミス
もし業務ルールにおいて受注より(時系列上で)先行して受注が発生する可能性があるなら、
受注テーブルに商品番号カラムを設けてはならない
代わりに受注番号カラムと商品番号カラムを持つ受注.商品.対応テーブルを追加し、
両カラムのペアにはユニーク制約を、各カラムには参照整合性制約を設定する
この設計は、できれば業務分析時に判断してあらかじめDB設計に盛り込むのがベストであるし、
あるいは分析漏れがあったのならば(分析ミスを認めて)バグを作り込んだDBの再設計に立ち返るべき
こうした上流工程での間違いを正さずに下流工程のアプリ側で整合性検査処理を組ませるからバグが多発する
いいかえると、上流でのミスを下流の小手先で誤摩化そうとする傲慢さがプロジェクト炎上の原因になる
システム設計の基礎である初歩的なアルゴリズムの知識が無く、DB設計の基本や品質保証の定石も知らず、
これでもNTTデータ様のITスペシャリストを名乗れている(>>107)という現実に驚かされる
そして、これほど無能な自称スペシャリストに記事を書かせたITproの見識にも、疑いをいだかざるをえない
113:NAME IS NULL
14/02/28 01:03:50.30 .net
>>112の「....」の部分を訂正
誤: もし業務ルールにおいて「受注」より(時系列上で)先行して受注が発生する可能性があるなら、
正: もし業務ルールにおいて「商品(の登録)」より(時系列上で)先行して受注が発生する可能性があるなら、
114:NAME IS NULL
17/12/29 11:52:31.98 dtNZwIie.net
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
8IA9EN4TR2