Q&A
退会済みユーザー
総合スコア0
投稿2022/08/04 08:12
例えば、下記のマスターと売上テーブルがあるとします。
また、世代は、2→3→4と、毎日のように新しい世代がINSERTされます。
※雑な例なので、売り上げデータの主キーが重複してるんじゃ？とかは無視して下さい・・・
世代マスター
| 世代NO | 登録日時 | 最終編集日時 |
|---|---|---|
| 1 | 2022-01-01 12:00:00 | 2022-01-02 16:00:00 |
| 2 | 2022-01-02 13:00:00 | null |
| 3 | 2022-01-03 12:00:00 | 2022-01-05 12:00:00 |
従業員マスター(主キーは、従業員CDと世代の複合主キー)
| 従業員CD | 氏名 | 連絡先 | 世代 |
|---|---|---|---|
| EM0001 | 岡本 和真 | 0000-00-0000 | 1 |
| EM0002 | 吉川 尚輝 | 0001-01-0001 | 1 |
| EM0003 | 丸 佳浩 | 0002-02-0002 | 1 |
商品マスター(主キーは、商品コードと世代の複合主キー)
| 商品コード | 商品名 | 単価 | 世代 |
|---|---|---|---|
| CD0001 | 商品1 | 1000 | 1 |
| CD0002 | 商品2 | 1500 | 1 |
| CD0003 | 商品3 | 2000 | 1 |
売上データ ( トランザクションデータ )
| 売上CD | 商品コード | 商品名 | 単価 | 数量 | 合計金額 | 登録者CD | 世代 |
|---|---|---|---|---|---|---|---|
| S0001 | CD0001 | 商品1 | 1000 | 2 | 2000 | EM0001 | 1 |
| S0001 | CD0002 | 商品2 | 1500 | 1 | 1500 | EM0001 | 1 |
| S0002 | CD0002 | 商品2 | 1500 | 4 | 6000 | EM0002 | 1 |
| S0002 | CD0003 | 商品3 | 2000 | 2 | 4000 | EM0003 | 1 |
過去に登録されたトランザクションデータ（上記でいえば売上データ）に誤りがあれば、当時のマスターを修正した上で、
トランザクションデータに反映させたいのです。
※例えば、世代1の時の、従業員CD:EM0001の方の名が「和真」は誤登録で、本当は「一馬」であり、「一馬」に修正した場合、
売上データ (売上CD S0001)の登録者CDで登録者名を参照した場合、下記の状態にしたいのです。
修正前：岡本 和真 が表示される。
修正後：岡本 一馬 が表示される。
指定した世代のマスターを元に、その世代のマスターを元に登録されたトランザクションデータを修正したいので、
全世代の全データを保管する必要があり、どれかのテーブルに新世代が追加されると、
変更されていないテーブルも、変更されていないデータを新世代として追加する必要が出てきます。
※変更されていないテーブルも、常に変更対象候補でありつづける為。
そうするとデータ量が膨大になってしまいます。
全ての世代の全てのデータを1つのテーブルに登録すると、1カ月で1億レコードを軽く超えるようなテーブルが大量生産されます。
現行世代用のテーブルと過去世代用のテーブルを分離した場合でも、過去テーブルはどんどん肥大化していきます。
データの肥大化を避けるために、どのような設計にするべきでしょうか？
回答1件
0
通常、マスターデータと履歴データは別のテーブルに、マスターテーブルと履歴テーブルに分けます。
WHERE句でPRIMARY KEY に対して = イコールでSELECTできるのでパフォーマンスは良いです。
従業員CDと世代をPRIMARY KEYにすると範囲検索になってしまうので、SQLが複雑になるし、パフォーマンスが落ちます。
トランザクションデータには商品名や従業員名は持たずに、必要ならマスターとSELECT ... JOIN ...で取得します。
実際にCREATE TABLEとINSERTでデータを用意してSQLを書いてみては？質問は修正できます。
なお、個人的に15年以上前ですが、マスターと履歴を同じテーブルで設計する主義って人に会ったとこがあります。破綻するところを見たくなかったので、わたしは3ヶ月で契約を終えました。
投稿2022/08/04 08:35
総合スコア16415
あなたの回答
tips
プレビュー
