电商比价网站场景下是否需要对数据库进行规范化设计？

嘿，这个场景我刚好有过类似的实践经验，咱们来好好聊聊你的问题～

首先拆解下你提到的两个方案的核心问题：

方案1（单表存数组）的潜在隐患 #

你觉得方案1查询快，这点在数据量小的时候确实成立，但随着商品和店铺数量增长，会暴露出很多致命问题：

• 维护成本极高：新增店铺得修改数组结构；店铺改名要遍历所有商品的数组逐一更新，极易出错。
• 查询灵活性极差：比如想查「所有在shopA售价低于100$的商品」，要么全表扫描后在应用层解析过滤，要么依赖数据库JSON函数——但这种查询的性能远不如索引优化的结构化查询。
• 无法利用索引：数组里的店铺名和价格没法单独建索引，数据量上去后，单条查询的性能反而会比规范化结构差很多。
• 数据冗余与不一致：店铺名称会在每个商品的数组里重复存储，不仅浪费空间，还容易出现拼写错误（比如shopB写成shopB_）导致数据不一致。

方案2（拆分多张店铺表）的优化方向 #

你说方案2需要多次查询其实是个误区——完全不用给每个店铺单独建表，正确的规范化做法应该是两张表：

1. table_product_info：存储商品基础信息

   ID=48, Name="shoesA", Brand="brandA"
   

2. table_product_prices：存储商品-店铺-价格的关联关系，结构为ID, Product_ID, Shop_Name, Price

   ID=1, Product_ID=48, Shop_Name="shopA", Price=107
   ID=2, Product_ID=48, Shop_Name="shopB", Price=114
   ID=3, Product_ID=48, Shop_Name="shopC", Price=97
   

要获取某个商品的全部价格，只需要一次JOIN查询就能搞定：

SELECT pi.*, pp.Shop_Name, pp.Price
FROM table_product_info pi
JOIN table_product_prices pp ON pi.ID = pp.Product_ID
WHERE pi.ID = 48;

这种方式的查询性能和方案1几乎无差，甚至数据量大时，因为可以给Product_ID和Shop_Name建联合索引，性能会更优。

要不要做数据库规范化？ #

我的建议是一定要做规范化，原因如下：

• 数据一致性有保障：如果后续店铺信息需要修改（比如改名、加店铺地址），只需要维护关联表（甚至可以再建一张table_shops存店铺基础信息，用Shop_ID关联，更规范），不会出现数据不一致的情况。
• 扩展性极强：新增店铺、新增价格相关字段（比如促销价、库存），只需要调整关联表结构，不用动商品主表。
• 覆盖所有查询场景：不管是查单商品多店铺价格，还是查单店铺多商品价格，或是做价格区间筛选，都能通过SQL高效实现，不用在应用层做大量数据处理。

当然，如果你的业务极端简单（比如永远只有3个店铺，不会新增，也不会有复杂查询），方案1可能暂时能用，但从长远业务发展来看，规范化的结构才是可持续的选择。

内容的提问来源于stack exchange，提问作者Andrei Mikhov