制約っていらなくね？

**NAME IS NULL** · 2005/07/30(土) 22:52:42

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

**NAME IS NULL** · 2005/07/31(日) 02:33:05

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

**NAME IS NULL** · 2005/07/31(日) 03:00:10

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

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

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

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

**NAME IS NULL** · 2005/07/31(日) 03:03:30

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

**NAME IS NULL** · 2005/08/01(月) 05:30:05

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

**NAME IS NULL** · 2005/08/01(月) 10:31:03

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

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

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

**NAME IS NULL** · 2005/08/01(月) 10:48:40

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

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

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

**NAME IS NULL** · 2005/08/01(月) 12:08:59

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

**NAME IS NULL** · 2005/08/01(月) 22:58:35

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

**NAME IS NULL** · 2006/06/08(木) 23:51:07

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

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

**NAME IS NULL** · 2006/06/30(金) 00:59:24

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

**NAME IS NULL** · 2006/08/05(土) 00:40:54

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

**NAME IS NULL** · 2006/08/15(火) 00:15:31

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

**NAME IS NULL** · 2006/08/17(木) 11:00:08

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

**NAME IS NULL** · 2006/11/25(土) 01:59:26

てｓｔ

**NAME IS NULL** · 2007/03/18(日) 01:54:18

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

**NAME IS NULL** · 2007/10/27(土) 22:41:17

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

**NAME IS NULL** · 2007/11/05(月) 01:17:42

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

**NAME IS NULL** · 2008/06/21(土) 22:53:28

保守してみるか

**NAME IS NULL** · 2009/01/03(土) 00:07:53

>>74
確かに実装レベルでは、Oracleが特殊だが、SQL標準からすると、Oracleが正解。
でも、Oracle8とかOracle9のせいでOracle嫌いになってしまったけどね。
(バグが多いくせにパッチ当てるのも一苦労だし)

で、制約に関しては、参照整合性制約以外は、つけたほうがいいと思う。
参照整合性だけは微妙だと思うけどね。
でも、制約にすべてのエラーチェックを任せるのはいかがなものだと思うよ。
アプリ側でチェックして、最後の砦として、制約を使うのが正解だと思う。
昔みたアプリで、とりあえず、INSERTしてみて、エラーが出たら、制約違反です
とかの処理のがあったけど、言語道断だと思う。
後、デフォルト値(制約じゃないけど)も付けといてもいいと思う。
でも、デフォルト値に設定したいがために、INSERT文で指定しないってのは
言語道断だと思う。

**NAME IS NULL** · 2009/04/02(木) 10:03:38

言語道断・・げんごみちだん？

**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