订单的最佳数据库结构

我在处理订单的结构化数据库的两种方式之间徘徊。我不确定一种方式是否会比另一种更快。如果他们平等，那么它可能无关紧要，对吧？订单的最佳数据库结构

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

谢谢你们！

来源

2011-06-05 Flipper

我不仅看速度，还看功能。谁在乎它是否快速，如果它限制你太多而无用。例如，如果您想两次查看订单（您第一次拒绝某件事情），该怎么办？或者如果您将订单分成两部分呢？除非有商业案例，为什么你真的永远不会有这些的倍数，我会建议你的第二个选择。

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

最后，如果有疑问，我通常会选择可扩展模型。我很少碰到过一次，因为有一个过于标准化的数据库结构而自责（但我并没有过多），但是我遇到过一些令我感到沮丧的模型，因为它们无法使用（现在已经改变了）他们应该支持的用例。

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

来源

2011-06-05 01:21:37 IAmTimCorey

你刚刚给了我最好的答案！我会接受你的答案。但是，恰当的索引意味着什么？ – Flipper 2011-06-05 01:27:24

@Flipper - 当你建立你的表格时，确保为每个表格分配一个主键（可能是你的每个ID字段）。然后，当您创建外键字段以链接到主键时，请确保它们已编入索引。此外，索引您将在搜索语句的WHERE子句中使用的任何字段。不要发疯，并索引所有内容，但要确保至少有PK/FK字段索引，以便使这些连接正常工作。 – IAmTimCorey 2011-06-05 01:31:42

好的，所以我所有的表都有一个id字段，它是一个主键，并设置为在所有表中自动递增。然后，例如在表格订单中，reviewID将对应于评论表中的条目的ID。你是这个意思吗？ – Flipper 2011-06-05 01:38:33

我会得到多个表，性能的差异将可以忽略不计，只要你创建适当的索引。

来源

2011-06-05 01:09:25 mikerobi

那么多倍的优势是什么？ – Flipper 2011-06-05 01:18:48

我会去一个正常化的模型。如果审阅和处理与订单是多对一的，那就选择2.如果审阅和处理与订单是一对一的，那么选项1可能更容易处理读写数据（例如，一个插入与三个插入）。

来源

2011-06-05 01:21:46 btreat

订单的最佳数据库结构

回答

相关问题