重复订单
大家好，我正在开展一个学校项目，对于我的项目，我选择创建一个可以处理重复订单的电子商务系统。这是我的期末项目，我将于五月与计算机科学助理一起毕业。
请记住，这不是最终的解决方案，它基本上是此数据库设计的起点。
有关业务流程的一些背景知识。
- 客户将订购产品，并在结帐时指定是一次性订单还是每周/每月订单。
- 客户将指定一个地点来提取订单（此地点仅特定于订单）
- 如果订单的价值> 25.00 则接受，否则拒绝。
- 这将分别填充orders_test和order_products_test表，
- 后端人员将根据这两个表生成当天的交付报告。
- 他们将能够将其打印出来，并生成一份列表，列出哪些物品被运往哪个位置。 基于以下标准。
- date_of_next_scheduled_delivery = 当前日期
- 剩余_deliveries > 0
- 一旦他们对交货清单感到满意，他们将按“处理交货”按钮。
- 这将如下调整 order_products_test 表
- 从剩余交付中减去 1
- 将当前日期插入 date_of_last_delivery_processed
- 基于交付频率（即一次、每周、每月），它将更改
- order_products_test 表中的 date_of_next_scheduled_delivery 状态值可以是活动、保留或取消、过期
我只是想听听一些意见，看看我是否正确地处理了这个问题，或者我是否应该放弃这个方法并重新开始。
Hi everyone I'm working on a school project, and for my project I chose to create an ecommerce system that can process recurring orders. This is for my final project, I'll be graduating in May with an associates in computer science.
Keep in mind this is no where a final solution and it's basically a jumping off point for this database design.
A little background on the business processes.
- Customer will order a product, and will specify during checkout whether it is a one time order or a weekly/monthly order.
- Customer will specify a location in which to pick up their order (this location is specific only to the order)
- If the value of the order > 25.00 then it is accepted otherwise it is rejected.
- This will populate the orders_test and order_products_test tables respectively
- Person on the back end will have a report generated for deliveries for the day based on these two tables.
- They will be able to print it off and it will generate a list of what items go to what location.
Based on the following criteria. - date_of_next_scheduled_delivery = current date
- remaining_deliveries > 0
- Once they are satisfied with the delivery list they will press "Process Deliveries" button.
- This will adjust the order_products_test table as follows
- Subtract 1 from remaining_deliveries
- Insert current date into date_of_last_delivery_processed
- Based on delivery_frequency (i.e. once, weekly, monthly) it will change the date_of_next_scheduled_delivery
- status values in the order_products_test table can either be active, hold, or canceled, expired
I just would like some opinions if I am approaching this correctly or if I should scratch this approach and start over again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些想法，虽然不一定完整（您的问题有很多，但希望这些要点有所帮助）：
我认为您不需要跟踪剩余的交付。您只有 2 个选择 - 一次性订单或重复订单。在这两种情况下，计算剩余交付量是没有意义的。它永远不会被杠杆化。
在跟踪下一个交货日期方面，您只需跟踪订单当天即可。如果它是重复出现的——每月或每周，无论如何——一切都可以从第一次日期开始计算。大多数数据库系统（MySQL、SQL Server、Oracle 等）都支持足够的日期计算灵活性，以便您可以即时计算，而不是维护这样一个已知的时间表。
如果交货地点仅特定于订单，我认为为其创建单独的表没有任何用处 - 它在功能上依赖于订单，您应该将其保留在与订单相同的表中。对于大多数电子商务系统来说，情况并非如此，因为它们倾向于将交货地点列表与帐户相关联，当您多次订购时（例如亚马逊），它们会提示您。
鉴于上述情况，我打赌您可以只使用上面 4 个表中的 2 个——帐户和订单。但同样，如果交货地点与帐户相关联，我确实会打破这一点。 （但你上面的问题并不表明这一点）
不要用“_test”后缀命名你的表——这会令人困惑。
A few thoughts, though not necessarily complete (there's a lot to your question, but hopefully these points help):
I don't think you need to keep track of remaining deliveries. You only have 2 options - a one time order, or a recurring order. In both cases, there's no sense in calculating remaining deliveries. It's never leveraged.
In terms of tracking the next delivery date, you can just keep track of the day of the order. If it's recurring -- monthly or weekly, regardless -- everything is calculable from that first date. Most DB systems (MySQL, SQL Server, Oracle, etc) support more than enough date computation flexibility so that you can calculate this on the fly, as opposed to maintaining such a known schedule.
If the delivery location is only specific to the order, I see no use in creating a separate table for it -- it's functionally dependent on the order, you should keep it in the same table as the order. For most e-commerce systems, this is not the case because they tend to associate a list of delivery locations with accounts, which they prompt you about when you order more than once (e.g., Amazon).
Given the above, I bet you can just get away with 2 of your 4 tables above -- Account and Order. But again, if delivery locations are associated with Accounts, I would indeed break that out. (but your question above doesn't suggest that)
Do not name your tables with a "_test" suffix -- it's confusing.