MySQL - 打破更多表?

时间:2012-05-08 19:04:15

标签: mysql relational-database normalization

我正在创建一个订单系统来跟踪订单。大约有60种左右的产品,每种产品都有自己的价格。系统并不是很复杂,只需要能够提交人们订购的每种产品的数量。

我的问题是,拥有一个'orders'表是否更有效,其中列代表每个产品,数值代表他们订购的每个产品的数量..例如:

orders
    id
    product_a
    product_b
    product_c
    etc...

OR

我应该将它分成不同的表,并使用多对多表来加入它们。这样的事情可能是:

customers
     id
     name
     email

orders
     id
     customer_id

products
     id
     product

orders_products
     order_id
     product_id

4 个答案:

答案 0 :(得分:1)

我会像你在第二个样本中所展示的那样将它分开。这将使您的应用程序更具可扩展性,并且仍然非常高效。

答案 1 :(得分:0)

我也会使用第二种方式。如果你说的数据库简单,那么速度差异可能不大。但第二种方法更有效,更容易重用/增强,以防您获得新想法并添加到您的应用程序中。

答案 2 :(得分:0)

如果您选择第一种情况,您将如何跟踪每种产品为客户提供的价格和折扣?即使您现在没有计划跟踪它,这也是很常见的事情,因此可能会要求进行此类更改。

使用规范化架构,您只需添加几个字段即可。

答案 3 :(得分:0)

始终为未来功能和扩展而构建。当你不得不重新构建和重构整个事物时,这里或那里的捷径似乎总会让你感到困惑。查找规范化以及为什么要分离关系数据库中的每个独立元素。

我经常被问到“为什么要把它作为一个单独的表,这种方式更简单?”然后提醒他们“哦,我们将使用的这种类型的东西没有其他的东西”然后让他们要求一个需要多对多的功能,没有意识到他们通过不考虑未来的功能将你画成了一个角落。不了解数据结构的人往往无法实现这一点,并且在指定系统要求方面非常糟糕。这通常发生在数据库开始变大并且他们意识到他们希望只能查看数据子集时。平面数据库意味着添加列来处理大量不同的需求,而多对多连接表可以通过几行代码来实现。