如何正确将相关属性添加到mysql中的表中

Question

我们已经在我的工作地点开发系统有一段时间了，我觉得数据库设计有点失控了。

例如，我们有一个表格小部件（我有点欺骗这些小部件）：

+-----------------------+
|        Widget         |
+-----------------------+
| Id | Name     | Price |
| 1  | Sprocket | 100   |
| 2  | Dynamo   | 50    |
+-----------------------+
*There's about 40+ columns on this table already

我们希望为每个小部件添加一个属性以用于打包信息。我们需要知道它是否有包装信息，是否没有包装信息，或者我们不知道它是否有。然后，我们还需要存储包装详细信息的类型（假设它有或可能没有，它现在是冗余信息）。

我们已经有另外一张表来存储详细信息信息（我个人认为这张表应该分开，但这是另一个问题）。 PD = 包裹详情

+--------------------------------+
|       System Properties        |
+--------------------------------+
| Id  | Type     | Value          |
| 28  | PD       | Boxed          |
| 29  | PD       | Vacuum Sealed  |
+--------------------------------+
*There's thousands of rows in the table for all system wide table properties

本能地，我会创建许多映射表来捕获这些信息。然而，我被指示在每个表中添加另一列以避免进行连接。

我的解决方案：

创建表：

+---------------------------------------------------+
|                widgets_packaging                  |
+---------------------------------------------------+
| Id | widget_id | packing_info | packing_detail_id |
| 1  | 27        | PACKAGED     | 2                 |
| 2  | 28        | UNKNOWN      | NULL              |
+---------------------------------------------------+

+--------------------+
|     packaging      |
+--------------------+
| Id |               |
| 1  | Boxed         |
| 2  | Vacuum Sealed |
+--------------------+

如果我想知道一个小部件有什么包装，我可以加入到 widgets_packaging 中，如果我想知道确切的细节，我会再次加入到包装中。因此，小部件表上不再有列。

然而，有人告诉我忽略这一点，并将值 int 用于包装信息，并将另一个值作为外键放入系统属性表以查找包装详细信息。因此向表中添加另外两列，并在系统属性表中创建更多行来存储包详细信息。

+------------------------------------------------------------+
|                           Widget                           |
+------------------------------------------------------------+
|  Id | Name      |Price | has_packaging | packaging_details |
|  1  | Sprocket  |100   | 1             |  28               |
|  2  | Dynamo    |50    | 0             |  29               |
+------------------------------------------------------------+

这样做的原因是，如果您只想知道小部件是否有包装（有很多小部件），它更简单并且不涉及连接。他们担心更多的连接会减慢速度。

这里哪种解决方案更正确？他们对速度的担忧是否合理？我的直觉是，我们不能只是继续在小部件表中添加列，因为它正在增长，并且目前带有属性标志。

Answer 1

这个问题的答案实际上取决于使用该数据库的应用程序是读取密集型还是写入密集型。如果它是读取密集型的，则非规范化结构是一种更好的方法，因为您可以利用索引。连接更少，选择也更快。

但是，如果您的应用程序是写密集型的，那么规范化是一种更好的方法（您建议的结构是一种更规范化的方法）。表格往往更小，这意味着它们更有可能适合缓冲区。此外，规范化往往会减少数据重复，这意味着更新和插入只需在一个地方完成。

总结一下：

Write Intensive --> 规范化

• 较小的表更有可能适合缓冲区
• 更少的重复数据，这意味着更快的更新/插入

Read Intensive --> 去规范化

• 更好的索引结构
• 更少的连接意味着更好的性能

如果您的应用程序不是很重视读而不是写，那么更混合的方法会更好。