SQL-同じテーブルと関係制約を使用した多対多の関係
SellerProductテーブルがあります。テーブル内の各行は、販売者から提供された製品情報を表します。 SellerProductテーブルには次の列があります。
id (serial, pk)
productName (nvarchar(50))
productDescription (ntext)
productPrice (decimal(10,2))
sellerId (int, fk to Seller table)
商品はセラー間で同じである可能性がありますが、productName、productDescription、productPriceはセラーごとに異なる場合があります。
たとえば、製品TI-89を考えてみます。販売者Aは、製品に関する以下の情報を持っている可能性があります。
productName = TI-89 Graphing Calc
productDescription = A graphing calculator that...
productPrice 65.12
販売者Bは、製品に関する以下の情報を持っている可能性があります。
productName = Texas Instrument's 89 Calculator
productDescription = Feature graphing capabilities...
productPrice 66.50
管理ユーザーは、製品がさまざまな販売者で同じであることを識別する必要があります。
この情報を取得する方法が必要です（つまり、製品はセラー間で同じです）。次のように、SellerProductMapperという別のテーブルを作成できます。
sellerProductId1 (int, pk, fk to SellerProdcut table)
sellerProductId2 (int, pk, fk to SellerProdcut table)
このアプローチの問題は、sellerProductId1とSellerProductId2が特定の行の同じセラーからのものであることを許可することです。それは許されるべきではありません。
この制約を適用しながら、この多対多の関係をどのようにキャプチャできますか？
私の最初の反応は、あなたの主キーは一意性を保証するのに十分ではないということです。 ProductId、SellerIdの複合キーを検討する必要があると思います。それでも、テーブルに重複がある可能性があります。本当にバックアップして、実際のビジネス要件を確認する必要があると思います。たとえば、独自の製品をどのように「忠実に」キャプチャする必要があるか。多くの製造元は、大量のSKU（東芝のラップトップを時々見る）で基本的に同じ製品を製造しており、異なるディストリビューター/小売業者に異なるSKUを提供する場合があります。
また、余談ですが、プロダクションディスクリプションにNTextを使用したくない場合もあります。確かに、数百または数千の文字で十分です。
これが、多くの業界がSKU、UPCまたはその他の一意の識別子を適用する理由です。IDがない場合は、作成してデータベースにこの情報を入力させることができます。情報がそこで、必要なクエリを簡単に実行できます。