ECサイトを例に質問させて頂きます。
納品先テーブルと、受注テーブルがあります。
顧客は複数の納品先をあらかじめ登録しておくことが可能で、登録内容は後から自由に訂正できます。
- 納品先テーブル
顧客ID(複合PKEY)
納品先ID(複合PKEY)
氏名(漢字)
氏名(フリガナ)
郵便番号
都道府県
住所1
住所2
電話番号
メールアドレス
登録日時
変更日時
廃止フラグ
- 受注テーブル
受注No(PKEY)
顧客ID
納品先ID
受注日
受注商品CD
受注数量
…(以下略)…
このような設計のとき、顧客が発注した後に、顧客が納品先住所などを訂正(update)したら過去の発注実績がおかしくなります。
その対策として以下の案を考えてみました。
【案1】トランザクション全部乗せ
受注テーブルに氏名(漢字)、氏名(フリガナ)、郵便番号、都道府県、住所1、住所2、電話番号、メールアドレスをカラム追加する。
【案2】訂正と新規登録を区別しない
納品先に訂正があった場合は、updateでなくinsertを行う。(新しい納品先IDを振る)
訂正前のデータは廃止フラグを立てる。
【案3】世代管理する
納品先テーブルと受注テーブルに世代番号カラムを追加する。
納品先に訂正があった場合は、updateでなくinsertを行う。(納品先IDは同じで、新しい世代番号を振る)
顧客ID-納品先ID-世代番号で複合PKEYとする。
(メリットとデメリット)
案1はコードがシンプルになりますが、DBのデータ量が増えます。
案2は納品先ごとの集計ができなくなります。(要件的にまずい予感がする。)
案3はコードが複雑になりますが、DBのデータ量が減ります。(DBAによる手動メンテも楽)
皆様は普段どのように設計されているでしょうか。
よろしくお願いいたします。
回答1件
あなたの回答
tips
プレビュー