经常性订单

Question

大家好，我正在从事一个学校项目，对于我的项目，我选择创建一个可以处理经常性订单的电子商务系统。这是我的期末项目，我将于 5 月与计算机科学专业的同事一起毕业。

请记住，这不是最终解决方案，它基本上是此数据库设计的起点。

业务流程的一些背景知识。
- 客户将订购产品，并在结帐时指定是一次性订单还是每周/每月订单。
- 客户将指定取货地点（此地点仅针对订单）
- 如果订单的价值 > 25.00 则接受，否则拒绝。
- 这将分别填充 orders_test 和 order_products_test 表

• 后端人员将根据这两个表格生成当天的交货报告。
• 他们将能够将其打印出来，并生成一份清单，其中列出了哪些物品去往哪些位置。 基于以下标准。
• date_of_next_scheduled_delivery = 当前日期
• remaining_deliveries > 0
• 一旦他们对交付清单感到满意，他们将按下“处理交付”按钮。
• 这将调整 order_products_test 表如下
• 从remaining_deliveries 中减去1
• 将当前日期插入 date_of_last_delivery_processed
• 根据交付频率（即一次、每周、每月），它将更改 date_of_next_scheduled_delivery
• order_products_test 表中的状态值可以是活动、暂停或取消、过期

我只是想听听一些意见，如果我正确地处理了这个方法，或者我应该从头开始重新开始。

Answer 1

一些想法，虽然不一定完整（您的问题很多，但希望这些观点有所帮助）：

• 我认为您不需要跟踪剩余的交付。您只有 2 个选项 - 一次性订单或定期订单。在这两种情况下，计算剩余交付量都是没有意义的。它从未被利用过。

• 在跟踪下一个交货日期方面，您可以只跟踪订单的日期。如果它是重复的——每月或每周，无论如何——一切都可以从第一个日期开始计算。大多数数据库系统（MySQL、SQL Server、Oracle 等）都支持足够的日期计算灵活性，以便您可以即时计算，而不是维护这样一个已知的时间表。

1234563对于大多数电子商务系统而言，情况并非如此，因为它们倾向于将交货地点列表与帐户相关联，当您多次订购时它们会提示您（例如，亚马逊）。

• 鉴于上述情况，我敢打赌，您可以在上面的 4 个表中的 2 个表中逃脱 - 帐户和订单。但同样，如果交货地点与帐户相关联，我确实会打破这一点。 （但你上面的问题并不暗示）

• 不要使用“_test”后缀命名您的表——这会造成混淆。