购物车数据库架构

Question

我需要帮助为数据库创建架构以保存与 Web 用户的购物车/会话相关的信息。每个会话都有一个会话 ID、一个保持创建时间的时间戳、一个到期时间戳、一个指示购买是否完成的布尔值，然后是一个产品列表，以及它们相关的数量和价格。每个用户将只有一个 ID、原始时间戳、到期时间戳和购买布尔值，但他们可能会引用一种或多种具有不同数量和价格的产品。

我最初的想法是有一个会话表和一个产品表，但我似乎无法摆脱会话 ID 和产品信息在大订单和不同会话中变得多余的想法。简而言之，如果产品表的不同行始终引用重复的产品编号和会话 ID，是否会变得混乱？

我在正确的轨道上吗？或者您能否提出一种我尚未考虑的替代设计模式？

如果您需要更多信息，请告诉我。先感谢您！

Answer 1

根据您的描述，您将需要以下表格（“...”表示您可能需要该实体中的其他字段）：

• 用户（用户 ID、电子邮件地址、密码...）
• 会话（SessionID、CreatedDate、UserID、ExpiryDate、PurchaseCompleteInd ...）
• 产品（产品 ID、名称、单价...）
• SessionProductLink ( ProductID , SessionID , Quantity ...)

SessionProductLink 是一个Junction table，它是您遗漏的“设计的一部分”。

斜体的字段名称是外键（它们链接到哪些字段应该很明显......）。ID 字段是前三个实体中的聚集键字段，对于 SessionProductLink，您需要一个 (ProductID, SessionID) 的复合键。（如果需要，您可以在那里使用代理键，这是您可以做出的风格决定）

您可能需要考虑的其他事项：

• 安全。您想安全地加密存储您的用户密码（即使用 bcrypt），如果您支持信用卡，在大多数情况下，您在法律上不允许存储完整的信用卡详细信息，等等。
• 发票 - 您将支持哪些付款方式？您是否希望人们能够用一张发票支付多个“会话”的费用？（这对于企业账户比较常见，一般零售客户是一次购买=一张发票=一种付款方式）您要接受外币吗？（在这一点和第一点之间，你几乎需要一个支付处理器来确保你不会陷入大规模冲突......）
• 如果产品价格发生变化会怎样？您不希望您过去的购买/发票价格发生变化，对吗？
• 您需要永远存储您的会话（或至少已完成的会话）（取决于您所在国家/地区对商业交易文档存储的法律要求），因为它们是合法记录。同样，您不能只删除旧的产品记录，您需要将它们标记为过时，这样它们就不会显示为可供购买，但会显示在历史购买记录中（否则您的应用程序将显示某人购买的旧商品 5产品 ID 119 和产品 ID 135 的 2，你不知道他们到底买了什么......）。

这就是我现在能想到的所有内容，但这应该足以让您开始。