MySQL 规范化与非规范化

Question

我正在为买家和卖家创建一个在线市场。卖家的问题之一是“你们接受产品退货吗？”如果是这样，第二个问题是“谁支付退货的费用：买家还是卖家？”​​p>

我通常会选择标准化设计。因此，我通常会使用 items 表和 return_payers 表来设计这样的数据库并使用连接：

items
id  |  title |  description |  price    | returns_accepted | 
------------------------------------------------------------
 1  |  blah  |   blah blah  |   80.00   |     0  // No
 2  |  blah  |   blah blah  |  120.00   |     1  // Yes
 3  |  blah  |   blah blah  |   40.00   |     1  
 4  |  blah  |   blah blah  |   60.00   |     0 

return_payers
id |  item_id  | payer
--------------------------------
 1 |    2      |   1  //Buyer
 2 |    3      |   2  //Seller

但是因为这只是一个额外的信息，我想我可以像这样在产品上附加一个额外的列，从而减少连接的需要并可能加快阅读时间：

products
id  |  title |  description |  price    | returns_accepted | returns_payer
----------------------------------------------------------------------------
 1  |  blah  |   blah blah  |   80.00   |     0            |      NULL
 2  |  blah  |   blah blah  |  120.00   |     1            |         1
 3  |  blah  |   blah blah  |   40.00   |     1            |         2 
 4  |  blah  |   blah blah  |   60.00   |     0            |      NULL

我想知道的原因是因为我不仅有一个这样的例子，而且产品有很多这样的小问题，比如它有保修吗？是/否，如果是多长时间等。如果我说了 20 个这些小问题，规范化设计将需要 20 个具有 20 个连接的表，非规范化设计将有一个表，没有连接，但有很多 NULL 值。

因为它是一个在线市场，表格的阅读量将远远超过更新量。

欢迎咨询。谢谢。

Answer 1

这是一个哲学问题，因为会有很多 2c 意见和“根据我的经验”的想法。所以，在那个世界里，有一个：

只要明确定义了数据流程，对表进行非规范化是完全正常的。您的数据库需要在设计时考虑到两个想法：首先，它需要快速支持您的应用程序；其次，它必须尽可能面向未来，以防止随着您的数据持有量和应用程序的增长而出现瓶颈。

您的一个想法是构建规范化数据模型，以便您可以针对它执行商业智能，然后进行自动 ETL（数据传输），您可以在其中将数据非规范化到单独的聚合表中，超索引，支持您的运营。因为您是这样做的，所以您现在可以利用您的数据来进行未来的销售，而且您将有一个特定的表来支持您的操作。

值得注意的是，无论哪种方式，如果您计划对数据执行任何类型的分析，将规范化数据库（数据仓库）放在不同的服务器上，那么您的非规范化（操作数据库）将防止您的 Web 服务器减速在您进行分析时。

希望这会有所帮助。