制約っていらなくね？

**NAME IS NULL** · 2009/04/03(金) 21:37:01

>>99
3ヶ月掛けて考えたレスがそれか・・・

**NAME IS NULL** · 2009/04/24(金) 07:29:57

>>99
げんごどうだん

**NAME IS NULL** · 2009/07/02(木) 12:27:22

保守ついでに。

ITアーキテクトの「やってはいけない」
［データベース設計編］参照整合性制約機能を多用してはいけない
http://itpro.nikkeibp.co.jp/article/COLUMN/20090512/329851/

はてブでは否定的なコメントが多いが、このスレの住人的にはどうなんだろ？

**NAME IS NULL** · 2009/07/03(金) 18:04:26

ストアドよりインデックスの方が速いよ。

**NAME IS NULL** · 2009/07/19(日) 18:08:40

データベースの目的によるんじゃないか

ただのストレージとしてなら、参照性合成制約なんか邪魔なだけ
モデルをあらわすものなら、制約付けとくほうがいいのかな

**NAME IS NULL** · 2009/07/19(日) 22:31:04

商品番号のくだり馬鹿かよ

**NAME IS NULL** · 2009/08/02(日) 20:10:13

>>102
「参照制約を多用してはいけない」とは思うけど、
それは主にレスポンスの問題だな

こいつの挙げてる理由はどうでもいい
・移行時に時間がかかる
→移行なんてそうそうやるもんじゃないし、別に時間かかってもいい
・マスタにないデータが登録できない
→それが正常だし、アプリで制約実装しても同じ問題が起こる

**NAME IS NULL** · 2009/08/02(日) 20:47:06

藤塚勤也（ふじづかきんや）
NTTデータ基盤システム事業本部システム方式技術ビジネスユニット OSS技術統括エグゼクティブITスペシャリスト（データベース）
日頃はオリジナルOSSを中心に，技術開発やそのビジネス化に従事。
特にシステムの中核であるRDBMSには常に着目し，ITスペシャリストとして後進の指導にも注力している。
「RDBMS解剖学」（翔泳社）を共著。

データの人間ってこんなレベルのやつらばかりなのか？
こんなレベルで後進の指導に注力されてもこまるんだがｗ

**NAME IS NULL** · 2009/08/02(日) 20:53:12

基本丸投げで

**名無しさん＠そうだ選挙に行こう** · 2010/07/11(日) 16:56:08

データ社員が使えるとか何の笑い話だ？

**NAME IS NULL** · 2010/07/13(火) 15:20:02

> 通常業務処理の中でも問題になるケースがある。
> 例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。
ふむふむ。
> まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。
ああそうですか。
>仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。
まあそうですね。
>このような業務処理は実行できなくなってしまう。
えええ？
>仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。
はぁぁぁ？

お前が設計してはいけない。

【30.7m】 **電脳プリオン** · 2012/05/26(土) 14:52:17.07

せやな

**NAME IS NULL** · 2014/02/27(木) 19:09:42.31

>>102
>データを移行する際、先に受注テーブルを移行させようとすると
>参照整合性違反となり、RDBMSはエラーを返す。
>必ず、商品テーブルのデータ移行後に、
>受注テーブルのデータ移行を行わなければならない。

参照元-参照先という関係は半順序だからDAG(非循環有向グラフ)で表現できる
このDAGをトポロジカルソートすれば、
参照整合性違反にならないテーブルの移行順序を機械的に導出できる
これはグラフ・アルゴリズムの初歩的な応用だ(makeコマンドを知っていれば合点がつくと思う)

>仮受注のデータも受注テーブルで管理しようとしても、
>商品テーブルにない商品番号のデータは追加できない。
>このような業務処理は実行できなくなってしまう。

これは業務分析なりDB設計のミス
もし業務ルールにおいて受注より(時系列上で)先行して受注が発生する可能性があるなら、
受注テーブルに商品番号カラムを設けてはならない
代わりに受注番号カラムと商品番号カラムを持つ受注.商品.対応テーブルを追加し、
両カラムのペアにはユニーク制約を、各カラムには参照整合性制約を設定する

この設計は、できれば業務分析時に判断してあらかじめDB設計に盛り込むのがベストであるし、
あるいは分析漏れがあったのならば(分析ミスを認めて)バグを作り込んだDBの再設計に立ち返るべき
こうした上流工程での間違いを正さずに下流工程のアプリ側で整合性検査処理を組ませるからバグが多発する
いいかえると、上流でのミスを下流の小手先で誤摩化そうとする傲慢さがプロジェクト炎上の原因になる

システム設計の基礎である初歩的なアルゴリズムの知識が無く、DB設計の基本や品質保証の定石も知らず、
これでもNTTデータ様のITスペシャリストを名乗れている(>>107)という現実に驚かされる
そして、これほど無能な自称スペシャリストに記事を書かせたITproの見識にも、疑いをいだかざるをえない

**NAME IS NULL** · 2014/02/28(金) 01:03:50.30

>>112の「....」の部分を訂正
誤: もし業務ルールにおいて「受注」より(時系列上で)先行して受注が発生する可能性があるなら、
正: もし業務ルールにおいて「商品(の登録)」より(時系列上で)先行して受注が発生する可能性があるなら、

**NAME IS NULL** · 2017/12/29(金) 11:52:31.98

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

8IA9EN4TR2