【问题标题】:Best Database Structure for Orders订单的最佳数据库结构
【发布时间】:2011-06-05 01:00:46
【问题描述】:

我在两种构建数据库以处理订单的方式之间纠结。我不确定一种方法是否会比另一种更快。如果他们是平等的,那应该没关系吧?

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

谢谢大家!

【问题讨论】:

    标签: database-design orders


    【解决方案1】:

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

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

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

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

    【讨论】:

    • 你刚刚给了我最好的答案!我会接受你的回答。但是,正确的索引到底是什么意思?
    • @Flipper - 构建表时,请确保为每个表分配一个主键(可能是每个表中的 id 字段)。然后,当您创建外键字段以链接到主键时,请确保它们已被索引。此外,索引您将在搜索语句的 WHERE 子句中使用的任何字段。不要疯狂地为所有内容编制索引,但请确保至少为您的 PK/FK 字段编制索引,以使这些连接正常工作。
    • 好的,所以我所有的表都有一个作为主键的 id 字段,并在所有表中设置为自动递增。然后就像在订单表中一样,reviewID 将对应于评论表中条目的 id。这是你的意思吗?
    • @Flipper - 这是正确的。然后应该将 reviewID 编入索引。
    【解决方案2】:

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

    【讨论】:

    • 那么多重的优势是什么?
    【解决方案3】:

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-09-19
      • 1970-01-01
      • 2015-08-17
      • 2023-04-08
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多