SQL架构优化，如何避免联合？答案

【问题标题】：SQL schema optimization, how to avoid unions?SQL架构优化，如何避免联合？
【发布时间】：2017-09-13 23:40:21
【问题描述】：

假设有以下架构：

现在在这个架构中，它将拥有 10000 台冰箱、10000 台电视和 10000 台电脑。然后它将有 5000 个备件。要获取与计算机相关的所有备件，可以这样查询：

SELECT SP.name, C.name as computer
FROM spare_parts SP, computer_spare_part CSP, computers C
WHERE   CSP.spare_parts_id = SP.id
AND     CSP.computers_id = C.id

现在有了给定的备用 ID = 1，人们想要获取详细信息和相关对象（冰箱、电视、计算机）。

SELECT SP.name, F.name as equipment
FROM spare_parts SP, fridge_spare_part FSP, fridges F
WHERE   FSP.spare_parts_id = SP.id
AND     FSP.fridges_id = F.id
AND     SP.id = 1

UNION

SELECT SP.name, C.name as equipment
FROM spare_parts SP, computer_spare_part CSP, computers C
WHERE   CSP.spare_parts_id = SP.id
AND     CSP.computers_id = C.id
AND     SP.id = 1

UNION

SELECT SP.name, T.name as equipment
FROM spare_parts SP, television_spare_part TSP, television T
WHERE   TSP.spare_parts_id = SP.id
AND     TSP.televisions_id = C.id
AND     SP.id = 1

在这种情况下，有 2 个 SELECTS 将失败。想象一下备用 ID = 1 与一台计算机有关。冰箱和电视 SELECT 不会得到任何结果。

这将有额外的处理时间。

如何优化此查询或架构来解决此类问题？

【问题讨论】：

我不确定我是否喜欢这个架构。是你创造的，还是随任务交给你的？我可能会将所有备件放在一个表中。
将所有“产品”存储在一个表中，其中“产品类型”表和产品与备件链接表。您可能还有一个产品属性表（即“冷却能力”、“流明”、“处理能力”）。
@SloanThrasher，在您的解决方案中，仅通过一次查询无法获取所有详细信息（备件和产品属性）。
当然是。存储复杂产品的非常常见的方法。做了很多次。

标签： mysql database-design relational-database schema query-optimization

【解决方案1】：

每个产品及其各自备件的多个表是个坏主意

很难正确编码或使用框架，更难维护，查询也是噩梦。

所以使用具有相同列的主表并相应地拆分它们，因为：

将您的信息划分为基于主题的表格，减少冗余数据。应用规范化规则来检查它是否正确实施。

在你的情况下，表格应该是

Product (ProductId, ProductName)
ProductDes(ProductId, ProductType)
SpareParts(productid (FK), sparepart_name, brand)

您现在和以后都可以根据需要增强它们而不会出现问题。正确的索引表没有问题可以快速处理。

【讨论】：