制約っていらなくね？ (114ﾚｽ)
上下前次1-新
1(3): 04/06/17 23:49 ID:fs3qldjg(1) AAS
プログラム側で制御しろよ
85: 2005/08/01(月)10:48 ID:??? AAS
「保守を行わない開発メンバー」という
箇所を見落としてた。
とはいえ、統一したフォーマットの
DDL書いてくれるだけでも便利だと
思うのだけどな。
そういった観点か既に保守する立場と（略
86: 2005/08/01(月)12:08 ID:??? AAS
チラシの裏書いた本人だが、終盤はモデルツールでやりますよ。
ただ、概念から順次ツールに合わせて落としていくっていうのがどうも制限になって嫌で。
手法の１つとしてはツールの手順でもいいけど、設計ってそこまで理想的に出来ないこと多いし。
とりあえずの概念設計とかはチラシの裏というか裏紙が一番いい。
87: 2005/08/01(月)22:58 ID:??? AAS
そのままの意味だったとは。。。
そいつぁ 盲点だたよ (^ ^ ;
88: 2006/06/08(木)23:51 ID:??? AAS
ここで書き込んでいる人たちはずいぶん専門的な話題が多いようですが、
具体的にいったいどんな規模のどんなシステムに関わってるんでしょうか？？
ここでいう「中小」とはどれくらいのものを指すんだろう・・・。
89: 2006/06/30(金)00:59 ID:??? AAS
中…1000万行程度、数十テーブル程度で同時接続ユーザ数100人程度
小…100万行程度、数テーブル以下で列数最大20-100列、同時接続ユーザ数数名程度
90(1): 2006/08/05(土)00:40 ID:??? AAS
今やってるのは
100万行程度、数百テーブルで列数最大100列、同時接続ユーザ数数名程度
ですが・・・
91: 2006/08/15(火)00:15 ID:??? AAS
>90
あまり細かい事を気にすると頭髪的にチャレンジされている方々の仲間入りしちゃうぞ。
92: 2006/08/17(木)11:00 ID:??? AAS
きみは政治的に正しいやつだね
93: 2006/11/25(土)01:59 ID:??? AAS
てｓｔ
94(1): 2007/03/18(日)01:54 ID:??? AAS
プログラム側でわかりやすいエラーを出すのはもちろんだけど
制約があればプログラムがバグってても間違ったデータは入らないので
フェールセーフにはなるよね。プログラム側の制御はフールプルーフということで。
制約の付け方が間違ってたら設計者を死刑で。
95: 2007/10/27(土)22:41 ID:??? AAS
制約は、Not Null、主キー、一意制約くらいいしか使わない
96: 2007/11/05(月)01:17 ID:??? AAS
>>94
自分もそう思って、可能な限り設計通りに参照整合性制約とか実装してる。
最近はマシンの性能も追いついて来た感じがあるし、設計と実装の乖離が
なくなってイイ感じ。
97: [age] 2008/06/21(土)22:53 ID:??? AAS
保守してみるか
98: 2009/01/03(土)00:07 ID:3emwlJX+(1) AAS
>>74
確かに実装レベルでは、Oracleが特殊だが、SQL標準からすると、Oracleが正解。
でも、Oracle8とかOracle9のせいでOracle嫌いになってしまったけどね。
(バグが多いくせにパッチ当てるのも一苦労だし)
で、制約に関しては、参照整合性制約以外は、つけたほうがいいと思う。
参照整合性だけは微妙だと思うけどね。
でも、制約にすべてのエラーチェックを任せるのはいかがなものだと思うよ。
アプリ側でチェックして、最後の砦として、制約を使うのが正解だと思う。
昔みたアプリで、とりあえず、INSERTしてみて、エラーが出たら、制約違反です
とかの処理のがあったけど、言語道断だと思う。
後、デフォルト値(制約じゃないけど)も付けといてもいいと思う。
でも、デフォルト値に設定したいがために、INSERT文で指定しないってのは
言語道断だと思う。
99(2): 2009/04/02(木)10:03 ID:??? AAS
言語道断・・げんごみちだん？
100: 2009/04/03(金)21:37 ID:??? AAS
>>99
3ヶ月掛けて考えたレスがそれか・・・
101: 2009/04/24(金)07:29 ID:??? AAS
>>99
げんごどうだん
102(2): 2009/07/02(木)12:27 ID:??? AAS
保守ついでに。
ITアーキテクトの「やってはいけない」
［データベース設計編］参照整合性制約機能を多用してはいけない
外部ﾘﾝｸ:itpro.nikkeibp.co.jp
はてブでは否定的なコメントが多いが、このスレの住人的にはどうなんだろ？
103: 2009/07/03(金)18:04 ID:??? AAS
ストアドよりインデックスの方が速いよ。
104: 2009/07/19(日)18:08 ID:??? AAS
データベースの目的によるんじゃないか
ただのストレージとしてなら、参照性合成制約なんか邪魔なだけ
モデルをあらわすものなら、制約付けとくほうがいいのかな
105: 2009/07/19(日)22:31 ID:??? AAS
商品番号のくだり馬鹿かよ
106: 2009/08/02(日)20:10 ID:??? AAS
>>102
「参照制約を多用してはいけない」とは思うけど、
それは主にレスポンスの問題だな
こいつの挙げてる理由はどうでもいい
・移行時に時間がかかる
→移行なんてそうそうやるもんじゃないし、別に時間かかってもいい
・マスタにないデータが登録できない
→それが正常だし、アプリで制約実装しても同じ問題が起こる
107(1): 2009/08/02(日)20:47 ID:??? AAS
藤塚 勤也（ふじづか きんや）
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 エグゼクティブITスペシャリスト（データベース）
日頃はオリジナルOSSを中心に，技術開発やそのビジネス化に従事。
特にシステムの中核であるRDBMSには常に着目し，ITスペシャリストとして後進の指導にも注力している。
「RDBMS解剖学」（翔泳社）を共著。
データの人間ってこんなレベルのやつらばかりなのか？
こんなレベルで後進の指導に注力されてもこまるんだがｗ
108: 2009/08/02(日)20:53 ID:??? AAS
基本丸投げで
109: 名無しさん＠そうだ選挙に行こう 2010/07/11(日)16:56 ID:??? AAS
データ社員が使えるとか何の笑い話だ？
110: 2010/07/13(火)15:20 ID:??? AAS
> 通常業務処理の中でも問題になるケースがある。
> 例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。
ふむふむ。
> まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。
ああそうですか。
>仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。
まあそうですね。
>このような業務処理は実行できなくなってしまう。
えええ？
>仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。
はぁぁぁ？
お前が設計してはいけない。
111: 【30.7m】 電脳プリオン 2012/05/26(土)14:52 ID:??? AAS
せやな
112(1): 2014/02/27(木)19:09 ID:??? AAS
>>102
>データを移行する際、先に受注テーブルを移行させようとすると
>参照整合性違反となり、RDBMSはエラーを返す。
>必ず、商品テーブルのデータ移行後に、
>受注テーブルのデータ移行を行わなければならない。
参照元-参照先という関係は半順序だからDAG(非循環有向グラフ)で表現できる
このDAGをトポロジカルソートすれば、
参照整合性違反にならないテーブルの移行順序を機械的に導出できる
これはグラフ・アルゴリズムの初歩的な応用だ(makeコマンドを知っていれば合点がつくと思う)
>仮受注のデータも受注テーブルで管理しようとしても、
>商品テーブルにない商品番号のデータは追加できない。
>このような業務処理は実行できなくなってしまう。
これは業務分析なりDB設計のミス
もし業務ルールにおいて受注より(時系列上で)先行して受注が発生する可能性があるなら、
受注テーブルに商品番号カラムを設けてはならない
代わりに受注番号カラムと商品番号カラムを持つ受注.商品.対応テーブルを追加し、
両カラムのペアにはユニーク制約を、各カラムには参照整合性制約を設定する
この設計は、できれば業務分析時に判断してあらかじめDB設計に盛り込むのがベストであるし、
あるいは分析漏れがあったのならば(分析ミスを認めて)バグを作り込んだDBの再設計に立ち返るべき
こうした上流工程での間違いを正さずに下流工程のアプリ側で整合性検査処理を組ませるからバグが多発する
いいかえると、上流でのミスを下流の小手先で誤摩化そうとする傲慢さがプロジェクト炎上の原因になる
システム設計の基礎である初歩的なアルゴリズムの知識が無く、DB設計の基本や品質保証の定石も知らず、
これでもNTTデータ様のITスペシャリストを名乗れている(>>107)という現実に驚かされる
そして、これほど無能な自称スペシャリストに記事を書かせたITproの見識にも、疑いをいだかざるをえない
113: 2014/02/28(金)01:03 ID:??? AAS
>>112の「....」の部分を訂正
誤: もし業務ルールにおいて「受注」より(時系列上で)先行して受注が発生する可能性があるなら、
正: もし業務ルールにおいて「商品(の登録)」より(時系列上で)先行して受注が発生する可能性があるなら、
114: 2017/12/29(金)11:52 ID:dtNZwIie(1) AAS
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
8IA9EN4TR2
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.324s*