【より良い】データモデリング【モデルを】 (542ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
387(4): 2006/03/10(金)08:45 ID:pPH8uClm(1) AAS
最近？でも無いのかも知れないけど、IDとCDの使い分けを
推奨する読み物を見掛ける事があるのですが実際の所どう思います？
●定義
ID:ユーザが意識しないシステム上での識別子
CD:ユーザが意識する識別子
この定義までは、同意です。
この後、CDを使う場合は、IDを主キーとし、
CDには、ユニークインデックスを張るという解説がよくみるパターンです。
この通りに進めると確かにCDは変更できるのですが、
モデルが複雑になりアプリの開発工数が確実に増えます。
省5
391: 387 2006/03/12(日)03:12 ID:??? AAS
>>388
>(1) joinするときに便利（複合主キーの場合）
４階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に
代替となるIDを振る事には、同意です。
気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。
例えば、↓こんなテーブル
取引先テーブル
取引先ID（主キー）
取引先CD（ユニーク制約）
取引先名（単なる属性項目）
省15
392: 387 2006/03/12(日)03:14 ID:??? AAS
>>389
>仕様変更とか柔軟になるし要求側には出来る限り押し通す
う〜ん、本当にそこまでやるメリットがあるのか
私の経験上わからないのですよねぇ。
ちなみに開発してきたのは、中小規模で数人で分析〜リリースし
半年位の規模で、受注だとか会計だとかのシステム。
>>390
>モデリングする段階ではCDを主キーとして、IDは実装段階で
>主キーにするのでは。
そのようですね。
省3
393: 387 2006/03/12(日)03:15 ID:??? AAS
IDとCDを分ける、最大のメリットはCD値の柔軟な変更だと
思っているのですが、変更できないといっている原因は、
参照整合性制約が理由ですかねぇ？
だとしたらCD値を主キーとして、参照整合性制約にON UPDATE CASCADEを
付加する方が、シンプルで柔軟性も確保でき負荷軽減という点でもメリットが
大きいと思うんですよねぇ・・・
ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、
使用可：SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。
使用不可：Oracle（Oracleで使えんのは問題か。。？）
396: 387 2006/03/13(月)20:57 ID:??? AAS
>自分は主キーは更新しないって前提で組むな。
私も基本は、主キーは変更しないという考えです。
というか、CDだろうがIDだろうが、一度付けた識別子を、
変更するな、という旧い？考えなのです。
ただ、会社として扱うデータ量、種類が増えてきた為に
コード体系を、変更したいといった要望が発生するのは
分かるので、コードを変更する上で効率的なモデリングは、
どんなのかなぁと考えている所です。
まぁ、そんな状況になった場合は、CDだけじゃなくシステム
全面見直しな上、会社として儲かっている可能性が高い訳で、
省27
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.770s*