SQL：多供應商市場的購物車設計
我正在開發一個 B2B 市場，使用者可以從不同的供應商/供應商處訂購。下圖是我原始架構中的範例，用於闡明購物車功能。
該
cart_item表將保存與其product.supplier_id匹配的產品，cart.supplier_id因為使用者將擁有供應商的特定購物車。cart這裡需要桌子嗎？還是我應該擺脫cart桌子並直接連接cart_item到user桌子？範例圖像
在建模中，重要的是要了解為什麼選擇特定設計而不是做以前做過的事情。
因此，從您單獨展示的內容來看，供應商可以確定他們的哪些產品在購物車中，因此不需要直接連結到購物車。從相同的數據來看，沒有供應商，就沒有必要有一個購物車錶，因為它沒有明顯的理由存在。因此，模型中真正應該擁有的只是對其供應商具有外鍵的產品，以及對產品和使用者具有外鍵的購物車項目。
從這個級別開始，您現在可以確定您需要/不需要什麼。如果您更改了與使用者相關的資訊，例如必須為每個購物車項目輸入的運輸資訊，這是一個很好的理由以購物車實體的形式引入摘要，並且購物車項目中的 user_id 外鍵移動到購物車（如你擁有了它）。
如果存在需要為每個購物車項目輸入（選擇）的供應商故障（例如特定地址的特許經營權或基於位置的銷售稅），那麼這就需要在購物車項目中包含外鍵最終移動到購物車以防止重複。如果沒有供應商細分或需要輸入與購物車中的供應商相關的任何新資訊，則無需在購物車/購物車項目中引用供應商，因為產品已經知道其供應商。
至於外鍵、唯一鍵和主鍵，出於物理模型中的性能原因，模式為：
PrimaryKey：命名模式<實體名稱（單數）>_ID 中的自動遞增值，例如 caritem_id 或 CartItemID。
UniqueKey：在唯一鍵上添加唯一約束，例如在購物車項目中的 (product_id, user_id) 或供應商中的供應商名稱上。在關聯表中，這些通常位於外鍵組合上。
外鍵：這些是對其源表中自動遞增值的引用，因此與它們引用的值具有相同的數據類型和名稱。