3

我在两种构建数据库以处理订单的方式之间纠结。我不确定一种方法是否会比另一种更快。如果他们将是平等的，那么这可能不重要，对吧？

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

多谢你们！

4

3 回答 3

4

我不仅会关注速度，还会关注功能。谁在乎它是否很快，如果它限制了你太多有用。例如，如果您想两次查看订单（可能是第一次拒绝某件商品）怎么办？或者，如果您分两部分处理订单怎么办？除非有商业案例说明你真的永远不会拥有其中任何一个的倍数，否则我会建议你的第二个选择。

另外，不要忘记反过来也可能是正确的。例如，一个人可能一次处理三个订单。或者他们可能一次批准三个订单。也许这些现在还没有发生，但你需要评估未来。确保您的数据库模型适用于您和您的用例。

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

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

于 2011-06-05T01:21:37.787 回答
1

我会得到多个表，只要您创建正确的索引，性能上的差异就可以忽略不计。

于 2011-06-05T01:09:25.163 回答
1

我会使用标准化模型。如果评论和处理与订单是多对一的，请使用选项 2。如果评论和处理与订单是一对一的，则选项 1 可能更容易用于读取和写入数据（例如，一个插入与三个）。

于 2011-06-05T01:21:46.273 回答