我有这个当前设置：
产品
product_id | product_name | category_id
类别
category_id | category_name
小贩
vendor_id | vendor_name | vendor_status
供应商价格
vendor_id | product_id | vendor_price
据我了解，根据规范化的“规则”，应该还有 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 种产品，每个产品都有几个不同的供应商，每个供应商的价格都不同，这使得它在 Sphinx 中算作超过 150 万份文档。
我的设计是错的，还是将其更改为更规范的设计会有什么好处？
更新
我还有一张桌子来存放所有产品类别。我已经更新了上面的架构，在最初的帖子中忘记了。
通常，我根据类别拆分查询，并为所有所属产品查询每个类别。当用户单击产品时，我会查询该特定产品的所有价格并按降序显示价格。
因为可以暂停供应商 (vendor.vendor_status)，所以所有查询都必须通过几个返回到供应商表的连接来执行。
在插入中，我从特定供应商处删除产品中的所有内容，由于外键约束，来自同一供应商的所有供应商价格也会被删除。然后我在 product 和 vendor_price 中插入一个新的。
希望这是有道理的。
更新 2
今晚进行了大量查询测试后，我发现将 vendor_status 保存在 vendor 表中确实会减慢很多速度。
因为数据库每次选择价格时都必须在 vendor_price 和 vendor 之间加入选择，这对于获取例如：
MIN(vendor_price) AS min_vendor_price, MAX(vendor_price) AS max_vendor_price)
在每个 vendor_price 行中保留 vendor_status 的副本将意味着大量冗余数据，但它确实加快了选择速度。
从
查询耗时 7.8040 秒
至
查询耗时 3.1640 秒
当数据集变得如此庞大时，我想这是优化查询和使用大量缓存功能之间的平衡问题。即使在今天的硬件上，规范化也确实阻碍了速度。