database-design - 最佳订单数据库结构

Question

我在两种构建处理订单数据库的方法之间左右为难。我不确定一种方式是否会比另一种方式更快。如果它们是相等的，那么应该无关紧要，对吧？

这是选项 #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

谢谢大家!

Answer 1

我不仅要看速度，还要看功能。如果它对您的限制太多而无用，谁会在乎它是否快。例如，如果您想对订单进行两次审核(可能是第一次拒收)怎么办？或者，如果您分两部分处理订单怎么办？除非有商业案例说明为什么您真的永远不会拥有其中任何一个的倍数，否则我建议您选择第二个选项。

此外，不要忘记反过来也可能成立。例如，一个人可能同时处理三个订单。或者他们可能一次批准三个订单。也许这些现在不会发生，但你需要评估 future 。确保您的数据库模型适用于您和您的用例。

最后，如果有疑问，我通常会选择可扩展模型。我很少遇到过因为数据库结构过于规范化而责备自己的时候(我不会过火)，但我遇到过许多让我感到沮丧的模型，因为它们无法与(现已更改)它们应该支持的用例。

就速度而言，连接越多，速度就越慢。但是，除非您的数据库非常大，否则我们并不是在谈论巨大的速度问题。正确地编制索引，您很可能永远不会注意到差异。