购物车“订单”表的订单状态类型的最佳细分是什么？答案

【问题标题】：Whats the best breakdown of order status types for shopping cart 'Order' TABLE?购物车“订单”表的订单状态类型的最佳细分是什么？
【发布时间】：2009-11-17 20:36:09
【问题描述】：

我见过几种不同的购物车模式，其中包含用于订单状态类型/运输状态类型/付款状态类型的不同表。

我想在我的项目中第一次做到这一点，想知道最好的方法是什么，希望有人能提供示例表供我使用。

当然，关键是无论我使用多少列——它们必须代表互斥的东西。

我的想法是这样的：

OrderStatus - 摘要状态 PaymentStatus - 已付/未付/部分已付/错误 ShippingStatus - Unshipped/PartiallyShipped/Shipped/DeliveredByHand

最好的解决方法是什么 - 我是否应该有一个“摘要”状态也代表整个“人类可读”状态以及流程中每个独立部分的单独状态？

【问题讨论】：

标签： database-design shopping-cart

【解决方案1】：

任何时候您有各种“互斥”状态，这意味着有一个列具有该列的多个可能值。大多数情况下，这些值应该受到约束，最好和最常见的方法之一是通过“字典”或“查找”表的外键。所以，在最基本的情况下，你可能会有这样的事情：

表顺序（OrderID、OrderStatusID、...）
表 OrderStatus（OrderStatusID、名称）

OrderStatus 将具有以下值： * 1，“付费” * 2，“未付” * 3，“发货” * 4，“未发货”

重要的部分是确定哪些状态与其他状态真正互斥。例如，我上面的示例行可能不是很好，因为您可能有一个既是“已付款”又是“已发货”的订单。如果是这种情况，那么您可以将 OrderStatus 拆分为 PaymentStatus 和 ShippingStatus（正如您所提到的）。

决定是否拆分这些行实际上取决于您和您的特定需求。但是，无论您做出什么决定，都假设您将必须在某个时候对其进行更改。通常，唯一永远不会改变的应用程序/数据库是那些因缺乏使用而被放弃的失败应用程序/数据库。 “第一次做对”是一个令人钦佩的目标，提前进行研究是有必要的，但您几乎肯定不会实现它。相反，您应该努力使其余的设计/代码足够灵活和可更改，以便您可以重新设计其中的一部分，而不必破坏整个应用程序。

【讨论】：

是的，这可能是最重要的部分。过去的说法是“建一个扔掉”；如今，它更多的是关于较短的开发周期、重构和即时的客户反馈，但想法是一样的。整体式的前期设计方法被证明效果不佳。
旧帖子，但值得注意的是，如果您打算在任何类型的比较中使用订单的数字状态，您可能不想使用单个数字，而是使用更大的数字，即。 100、200 等，这样您就可以选择在其间插入新状态，即。 150 或 125。（或使用十进制数据类型）因为正如@CraigWalker 所说；如果它是一个实际使用的系统，很有可能你必须在某个时候改变它。

【解决方案2】：

这真的，真的取决于购物车本身的全部功能。我建议遵循 SDLC，它可以让您更好地了解您需要从哪些功能开始，从而更清楚地了解您需要在数据库中存储哪些数据（表/字段）。

这里有一些链接可以帮助您开始：

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle

一旦开始，您通常可以确定您在进行过程中需要哪些字段和值。

一旦确定需要在数据库中存储哪些数据，您就可以使用数据库规范化指南来帮助构建表格

http://en.wikipedia.org/wiki/Database_normalization

希望有帮助！

【讨论】：