納品先情報をトランザクションに持たせるか

Question

ECサイトを例に質問させて頂きます。

納品先テーブルと、受注テーブルがあります。
顧客は複数の納品先をあらかじめ登録しておくことが可能で、登録内容は後から自由に訂正できます。

• 納品先テーブル

顧客ID(複合PKEY)
納品先ID(複合PKEY)
氏名（漢字）
氏名（フリガナ）
郵便番号
都道府県
住所１
住所２
電話番号
メールアドレス
登録日時
変更日時
廃止フラグ

• 受注テーブル

受注No(PKEY)
顧客ID
納品先ID
受注日
受注商品CD
受注数量
…（以下略）…

このような設計のとき、顧客が発注した後に、顧客が納品先住所などを訂正(update)したら過去の発注実績がおかしくなります。
その対策として以下の案を考えてみました。

【案１】トランザクション全部乗せ

受注テーブルに氏名（漢字）、氏名（フリガナ）、郵便番号、都道府県、住所１、住所２、電話番号、メールアドレスをカラム追加する。

【案２】訂正と新規登録を区別しない

納品先に訂正があった場合は、updateでなくinsertを行う。（新しい納品先IDを振る）
訂正前のデータは廃止フラグを立てる。

【案３】世代管理する

納品先テーブルと受注テーブルに世代番号カラムを追加する。
納品先に訂正があった場合は、updateでなくinsertを行う。（納品先IDは同じで、新しい世代番号を振る）
顧客ID-納品先ID-世代番号で複合PKEYとする。

（メリットとデメリット）
案１はコードがシンプルになりますが、DBのデータ量が増えます。
案２は納品先ごとの集計ができなくなります。（要件的にまずい予感がする。）
案３はコードが複雑になりますが、DBのデータ量が減ります。（DBAによる手動メンテも楽）

皆様は普段どのように設計されているでしょうか。
よろしくお願いいたします。

Comments

[退会済みユーザー]

要件次第なので、要件が確定しないかぎり回答が出ない質問のように思います。
なにを問題としているのでしょうか？

[jk233]

ありがとうございます。
顧客が発注した後に、顧客が納品先住所などを訂正(update)したら過去の発注実績がおかしくなることが問題です。
そうならないために、どのような選択肢があるのか知りたいです。
後から色々な要望が出てくるので、柔軟な対応ができるようなシステムにしておきたいです。

[退会済みユーザー]

問題となる点に関して、すでに解決方法を持っていらっしゃるので、問題とはならないかと。
不安解消のための質問だと思いますが、要件をこちらが勝手にイメージするのはしんどいので、もう少し絞らないとアドバイスはつきにくい気がします。

Answer 1

各案のメリットデメリットは把握されておられるようなのであえてコメントするほどでないかもしれませんが。

ごく常識的には、案1が良い設計となります。
受注記録はそれで完結した1枚の帳票であり、他の台帳に依存するものではないと考えられるからです。

するとこう整理できます。
「納品先」はあくまで入力を楽にするだけのテンプレート、注文の際に受注記録へコピーされるだけの存在となります。
逆に言えば、スポットの納品で二度と使わないような納品先は、納品先テーブルにレコードを作るまでもなく発注の際に直に入力できる、そういうUIも用意できるということになります。

いかがでしょうか。