订单的最佳数据库结构

时间:2011-06-05 01:00:46

标签: database-design orders

我在构建数据库以处理订单的两种方式之间徘徊不前。我不确定一种方式是否比另一种更快。如果它们是平等的那么它可能不重要,对吗?

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

谢谢你们!

3 个答案:

答案 0 :(得分:3)

我不仅会关注速度,还会关注功能。谁在乎它是否很快,如果它限制你太多而无用。例如,如果您想要两次查看订单(第一次拒绝某些内容),该怎么办?或者如果您分两部分处理订单怎么办?除非有商业案例,为什么你真的永远不会有任何这些的倍数,我会建议你的第二个选择。

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

最后,如果有疑问,我通常会选择可扩展的模型。我很少遇到一个时间,因为我的数据库结构过于规范化(我不会过火),但我遇到了许多让我感到沮丧的模型,因为它们不能用于(现已更改)他们应该支持的用例。

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

答案 1 :(得分:1)

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

答案 2 :(得分:1)

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