【より良い】データモデリング【モデルを】 (542ﾚｽ)
上
下
前
次
1-
新
391
:
387
2006/03/12(日)03:12 ID:???
AA×
>>388
[240|
320
|
480
|
600
|
100%
|
JPG
|
べ
|
ﾚｽ栞
|
ﾚｽ消
]
391: 387 [sage] 2006/03/12(日) 03:12:21 ID:??? >>388 >(1) joinするときに便利（複合主キーの場合） ４階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に 代替となるIDを振る事には、同意です。 気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。 例えば、↓こんなテーブル 取引先テーブル 取引先ID（主キー） 取引先CD（ユニーク制約） 取引先名（単なる属性項目） >(2) 変更履歴を管理しやすい（コード変更時は直接変更ではなく古いコードに削除フラグを 立てる、という感じ） 削除フラグを使用するという事は、CDにはユニーク制約を 張らないという事ですね。 変更履歴を、作りやすいという点は、分かりました。 この方法で気になる事は、 ・CD値の重複チェックをアプリ側で徹底する必要がある。 ・変更のたびにレコードが増えて行くのは、 いたすらに負荷(JOIN等)を増やす事になるのでは？ ・CD値の変更を行った場合には、レコードが追加され 新しいIDが振られると思うのですが、 子テーブルとの紐付けはどうなるのでしょうか？ >(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきてい る（Hibernate,RoRなど） な〜るほど、それには従った方がよさそうですね。 http://mevius.5ch.net/test/read.cgi/db/1057509675/391
するときに便利複合主キーの場合 ４階層目のテーブルなどで主キーの項目数がやむえず増えた場合に 代替となるを振る事には同意です 気になっているのはでとを作成する事がどうなのかなぁと 例えばこんなテーブル 取引先テーブル 取引先主キー 取引先ユニーク制約 取引先名単なる属性項目 変更履歴を管理しやすいコード変更時は直接変更ではなく古いコードに削除フラグを 立てるという感じ 削除フラグを使用するという事はにはユニーク制約を 張らないという事ですね 変更履歴を作りやすいという点は分かりました この方法で気になる事は 値の重複チェックをアプリ側で徹底する必要がある 変更のたびにレコードが増えて行くのは いたすらに負荷等を増やす事になるのでは？ 値の変更を行った場合にはレコードが追加され 新しいが振られると思うのですが 子テーブルとの紐付けはどうなるのでしょうか？ 最近のアプリケーションフレームワークにシステムを前提にしたものが増えてきてい るなど なるほどそれには従った方がよさそうですね
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 151 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
ぬこの手
ぬこTOP
0.033s