sql - このデータベースサブタイプの関係はどのようにモデル化する必要がありますか？

Question

ショッピングカート機能が複数のベンダーと複数のクライアントを同じデータベースに格納する従来のマルチテナントアプリケーションを改訂しています。あるベンダーの一部のクライアントは、別のベンダーのクライアントである場合があります。一部のベンダーは、実際には別のベンダーのクライアントである可能性があります。

現在、主キーを持つスーパータイプ「party」party_IDのテーブル、主キーを持つサブタイプ「company」のテーブルcompany_ID（参照party_ID）、および主キーを持つ「vendor」の役割のテーブルvendor_ID（参照company_ID）があります。また、との複合主キーを持つジャンクションテーブル「client」もvendor_IDありparty_IDます。

私の質問は、「order」テーブルがベンダーテーブルとクライアントテーブルをどのように参照する必要があるかということです。私の最初の考えは、テーブルにはの複合主キーが必要でありvendor_ID、client_ID（order_IDテーブルorder_ID全体で自動インクリメントすることも、ごとにシーケンシャルにすることもできますvendor_ID + client_ID）、キーを構成する3つの属性があったため、これは少し厄介なようでした...

誰かがこのトピックについて何か洞察を持っていますか？ほとんどの「ショッピングカート」は単一のベンダーのみを扱っているため、注文表にclient_IDは外部キーとしてリストされているだけです。

ありがとう！

Answer 1

私の質問は、注文テーブルがベンダーテーブルとクライアントテーブルをどのように参照する必要があるかということです。私の最初の考えは、テーブルには「vendor_ID」、「client_ID」、「order_ID」の複合主キーが必要だということですが、3つのキーがあったため、これは少し厄介なようでした...

複合主キーは、3つのキーを意味するものではありません。これは、3つの列で構成される1つのキーを意味します。

しかし、それは本当の問題ではありません。

注文は会計記録です。時間の経過とともに変化してはなりません。一時テーブルを作成しない限り、ID番号を保存するのは危険ですが、それを行ったとは思えません。ベンダーが今日その名前を変更した場合、その名前は以前の注文の名前と一致しなくなります。会計記録でそれを起こさせてはいけません。

「order」で何か変わったことを意味しない限り、Order_idが主キーになると思います。他の制約があるかもしれません。Order_idのみが異なる重複注文を防ぐために、他の重要な制約がある場合もあります。ただし、Order_idが注文テーブルの主キーになることを期待しています。

ベンダーとクライアントがサブタイプである場合、サブタイプテーブルのID番号を参照するために保存する（リスクの高い）ID番号を期待します。あなたの場合、ベンダーのクライアントを識別する追加のテーブルがあるようです。{vendor_id、client_id}列が含まれています。そのテーブルの外部キー参照は明白であるはずです。

注文のテーブルには、ベンダーへの1つの外部キーとクライアントへの別の外部キーではなく、そのテーブルへの1つの外部キー参照が必要です。したがって、注文の表では、foreign key (vendor_id, client_id) references vendor_clients (vendor_id, client_id)。ベンダークライアントのテーブルには、{vendor_id、client_id}の主キー制約または一意性制約のいずれかが必要です。

ただし、時間テーブルを使用している場合を除いて、アカウンティングのためにこれを行うべきではありません。代わりに、おそらくID番号とテキストの両方を保存する必要があります。

Answer 2

主キーには、が必要ですorder_id。

実際、私が使用する複合（および一意の）キーは[ 、、vendor_id] （タイムスタンプです）になります-注文が1ミリ秒に1回しか出せないと仮定します。ただし、これはかなり広い鍵であり、一部のシステムはそれらを評価しません。ただし、これらの列は引き続き必要であり、おそらくインデックスが作成されます。client_idoccurredAtoccurredAt

Answer 3

私はこのようなものから始めます。company, vendor, and client私はあなたの質問の違いをまだ完全には理解していないことを認めます。Catcallが述べたように、このモデルでは削除することはできませんParties（People、Organizations）; 会計記録は凍結する必要があります-通常、注文テーブルに現在の顧客/サプライヤー情報をキャプチャすることによって。

---