订单的最佳数据库结构
我在两种构建数据库处理订单的方式之间左右为难。我不确定一种方法是否会比另一种方法更快。如果他们是平等的，那可能就不重要了，对吧？
这是选项#1。
orders
-------
id
timestamp
userID
cartID
reviewed
approved
reviewBy
reviewTimestamp
reviewDetails
processed
processedBy
processedTimestamp
processedDetails
选项#2：
orders
-------
id
timestamp
userID
cartID
reviewID
processID
reviews
-------
id
timestamp
status
reviewerID
details
processing
----------
id
timestamp
processorID
details
谢谢大家！
I am torn in between two ways of structuring my database for processing orders. I am not sure if one way will be faster than another. If they are going to be equal then it probably should not matter, right?
Here is option #1.
orders
-------
id
timestamp
userID
cartID
reviewed
approved
reviewBy
reviewTimestamp
reviewDetails
processed
processedBy
processedTimestamp
processedDetails
Option #2:
orders
-------
id
timestamp
userID
cartID
reviewID
processID
reviews
-------
id
timestamp
status
reviewerID
details
processing
----------
id
timestamp
processorID
details
Thanks guys!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不仅会关注速度，还会关注功能。如果它限制你太多而无法使用，谁会在乎它是否快。例如，如果您想两次审核订单（可能是第一次拒绝某些订单）怎么办？或者如果您分两部分处理订单怎么办？除非有商业案例，为什么你真的永远不会拥有其中任何一个的倍数，否则我会建议你的第二种选择。
另外，不要忘记反过来也可能成立。例如，一个人可能同时处理三个订单。或者他们可能会同时批准三个订单。也许这些现在还没有发生，但你需要评估未来。确保您的数据库模型适合您和您的用例。
最后，当有疑问时，我通常选择可扩展模型。我很少遇到过这样的情况：我因为数据库结构过于规范化而责备自己（我不会太过分），但我遇到过许多让我感到沮丧的模型，因为它们无法与（现已更改）它们应该支持的用例。
就速度而言，连接越多，速度就越慢。然而，我们并不是在谈论巨大的速度问题，除非您的数据库非常大。正确地建立索引，您很可能永远不会注意到其中的差异。
I would look not only at speed but also at functionality. Who cares if it is fast if it limits you too much to be useful. For example, what if you want to review an order twice (the first time you reject something maybe)? Or what if you process the order in two parts? Unless there is a business case why you really will never have multiples of any of these, I would suggest your second option.
Also, don't forget the reverse could be true as well. For example, one person might process three orders at once. Or they might approve three orders at once. Maybe these aren't happening now, but you need to evaluate the future. Make sure your database model works for you and your use cases.
Finally, when in doubt, I usually opt for the extensible model. I rarely come across a time when I kick myself for having a database structure that is too normalized (I don't go overboard) but I've come across a number of models that have frustrated me to no end because they are unworkable with the (now changed) use cases they are supposed to support.
As far as speed goes, the more you have joins, the slower it will go. However, we aren't talking about massive speed issues unless your database is incredibly large. Do your indexes properly and you most likely will never notice the difference.
我会得到多个表，只要您创建正确的索引，性能差异就可以忽略不计。
I would got with multiple tables, the difference in performance will be negligible, as long as you create the proper indexes.
我会选择标准化模型。如果审核和处理与订单是多对一的，请选择选项 2。如果审核和处理与订单是一对一的，则选项 1 可能更容易用于读取和写入数据（例如，一个插入与三个插入）。
I would go with a normalized model. If reviews and processing are many to one with orders, go with option 2. If reviews and processing are one to one with orders, option 1 may be easier to work with for both reading and writing data (ex. one insert vs three).