我有这个当前设置：
产品
product_id | product_name | category_id
类别
category_id | category_name
供应商
vendor_id | vendor_name | vendor_status
vendor_price
vendor_id | product_id | vendor_price
根据我的理解，根据＆＃34;规则＆＃34;正常化应该有2 更多的表格声明了这样的关系：
rel_product_vendor_price
product_id | vendor_price_id
rel_vendor_price_vendor
vendor_price_id | vendor_id
然后上面名为vendor_price的表将删除product_id 添加了vendor_price_id。
我没有看到创建两个表以保持一致的重点 因为它会使查询复杂化。特别是INSERTS很复杂，必须在交易中执行。
目前，这些表格拥有超过300,000种产品，每种产品都有几种 不同的供应商，每个不同的价格，使其数量超过 斯芬克斯有150万份文件。
我的设计错了，或者将其更改为更标准化的设计是否有任何优势？
更新
我有一张桌子可以容纳所有产品类别。我已经更新了上面的架构，忘了在最初的帖子中。
通常我会根据类别拆分查询，并查询所有所属产品的每个类别。当用户点击产品时，我会查询该特定产品的所有价格，并按降序显示价格。
由于可以暂停供应商（vendor.vendor_status），因此必须使用多个连接执行所有查询，并返回到供应商表。
在插入中，我删除了特定供应商的产品中的所有内容，同一供应商的所有供应商价格也会因外键约束而被删除。然后我在产品和vendor_price中插入一个新的。
希望这是有道理的。
更新2
今晚进行了大量的查询测试，我发现将vendor_status保留在供应商表中真的会减慢很多东西。
因为数据库必须在每次选择价格时加入vendor_price和供应商之间的选择，这对于获取价格非常重要：
MIN（vendor_price）AS min_vendor_price，MAX（vendor_price）AS max_vendor_price）
在每个vendor_price行中保留vendor_status的副本意味着有很多冗余数据，但它确实加快了选择速度。
来自
查询耗时7.8040秒
要
查询耗时3.1640秒
当数据集变得如此之大时，我想这是在优化查询和使用大量缓存功能之间取得平衡的问题。即使在今天的硬件上，标准化也确实会受到阻碍。
答案 0 :(得分：1)
规范化尝试消除冗余数据，因此插入/更新/删除不必一次处理多个表;相反，冗余数据可以通过消除大量连接的需要来加速查询，但是你必须在多个地方处理插入/更新/删除。您的3表架构对我来说很好，假设您只想根据供应商ID和产品ID查找价格，但请详细说明您希望运行的查询类型/您计划存储的其他类型的数据