我为买家和卖家创建了一个在线市场。对卖家来说，其中一个问题是＆＃34;你接受产品退货吗？＆＃34;如果是这样，第二个问题是＆＃34;谁支付退货项目：买方或卖方？＆＃34;
我总是经常选择标准化的设计。所以我通常会使用项表和 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值。
因为它是一个在线市场，所以这些表的阅读量远远超过它们的更新。
建议欢迎。感谢。
答案 0 :(得分：0)
这是一个哲学问题，因为在我的经验中会有很多2c的意见和＃34;那里的想法。所以，在那个世界里，有一个：
只要清楚地定义了数据流程，对表进行非规范化是完全正常的。您的数据库需要考虑两个想法：首先，它需要快速支持您的应用程序;第二，随着数据持有量和应用程序的增长，它必须尽可能地面向未来，以防止出现瓶颈。
您的想法是构建规范化数据模型，以便可以针对它执行商业智能，然后进行自动ETL（数据传输），您可以将数据非规范化为单独的聚合表，超索引，支持您的运营。因为您是这样做的，所以现在您可以利用您的数据进行未来的销售，而且您还可以使用特定的表来支持您的运营。
值得注意的是，无论哪种方式，如果您计划对数据执行任何类型的分析，将规范化数据库（数据仓库）放在不同的服务器上，那么非规范化（操作数据库）将防止Web服务器上的速度减慢当你在进行分析时。希望这有帮助。