问SQL:面向多供应商市场的购物车设计

EN

在建模中，重要的是要理解为什么选择特定的设计而不是做以前做过的事情。

因此，从您单独展示的情况来看，供应商可以知道他们的哪些产品在车内，因此不需要直接与大车连接。从相同的数据来看，如果没有供应商，就不需要有购物车表，因为没有明确的存在理由。因此，在模型中，您应该拥有的是向供应商提供外键的产品，以及向产品和用户提供外键的购物车项目。

从这个级别开始，您现在可以确定您需要/不需要什么。如果您更改了与用户相关的信息，比如必须为每个购物车项目输入的发货信息，那么就有充分的理由以购物车实体的形式引入一个摘要，并且购物车项中的user_id外键移动到购物车上(就像您拥有的那样)。

如果某一供应商(例如某一地址的特许经营权或按地点征收的销售税)需要为每一辆手推车项目输入(选择)，那就有理由在购物车项目中列入外键，最终转向购物车，以防止重复。如果没有供应商的详细信息或任何需要在购物车中与供应商绑定的新信息，则无需在购物车/购物车项目中引用供应商，因为产品已经知道其供应商。

对于外键、唯一键和主键，由于物理模型中的性能原因，模式如下：

PrimaryKey:命名模式中的自动递增值<实体名称(单数)>_ID或CartItemID。

UniqueKey:对购物车项目中的唯一键(product_id、user_id)或供应商名称添加唯一约束。在关联表中，这些通常是外键的组合。

外键:它们是对源表中的自动增量值的引用，与它们引用的值相同的数据类型和名称也是如此。

如果一个产品有多个供应商，并且客户选择了一个特定的供应商，那么您需要卡片中的供应商id。但你也可以在card_item中保存ot。

如果每个用户有多张卡片，您只需要一个卡片表。通常每个客户只有一张卡，您可以将其保存在这样一个表中供以后使用。所以我不明白，你为什么要给每个供应商一辆推车。如果您想让用户保持透明，就必须编写大量的逻辑。

你可以看看阿里巴巴，它是一个b2b系统。

每个购物系统的基本原理都是简单而愚蠢的，这样我们就可以使用它了。