关系型数据库通用值合理设计：如何为各车厂添加‘Other’车型

针对你提出的「每个车厂需额外拥有‘Other’车型」的需求，完全不需要采用多对多关系——数千个车厂的场景下，多对多会额外引入中间关联表，生成大量冗余关联记录，既浪费存储资源，也会增加查询复杂度，属于过度设计。下面是几种更务实的方案：

方案1：应用层/查询层动态拼接（无冗余存储） #

不需要在数据库中预存所有车厂的「Other」记录，而是在查询车型时，通过UNION ALL将真实车型与静态的「Other」条目合并，确保每个车厂的查询结果都包含该通用值。

示例SQL（以MySQL为例）：

-- 查询指定车厂的所有车型（含Other）
SELECT id, name 
FROM car_model 
WHERE make_id = 1
UNION ALL
SELECT 0, 'Other' 
FROM DUAL
-- 可选：避免重复（如果手动添加过Other记录）
WHERE NOT EXISTS (
    SELECT 1 
    FROM car_model 
    WHERE make_id = 1 AND name = 'Other'
);

你可以把这个查询封装成数据库视图或者应用层的通用查询方法，业务代码无需关心底层拼接逻辑。这种方案的优势是完全没有冗余数据，适合车厂数量极大且「Other」车型极少被单独使用的场景。

方案2：预生成专属「Other」记录（推荐） #

保留原有的一对多关系，给每个车厂生成一条专属的「Other」车型记录。比如给Opel（id=1）插入(NULL, 'Other', 1)，给BMW（id=2）插入(NULL, 'Other', 2)。

实现方式： #

• 触发器自动生成：在car_make表上创建插入触发器，当新增车厂时，自动在car_model中插入对应的「Other」记录。
• 批量初始化/补全：通过脚本一次性给现有所有车厂生成「Other」记录，后续新增车厂时通过后台任务或业务逻辑自动补全。

这种方案的优势非常明显：查询逻辑简单直接（无需UNION），数据语义清晰，且数千条「Other」记录的存储成本几乎可以忽略——关系型数据库轻松支撑十万级别的小数据量，完全不存在资源浪费的问题。相比多对多，它的结构更简洁，查询性能也更高。

方案3：全局通用「Other」记录（不推荐） #

在car_model中插入一条make_id为NULL的「Other」记录，查询时通过OR make_id IS NULL获取通用值。但这种方案的缺陷很突出：这条「Other」是全局共享的，无法区分属于哪个车厂，业务逻辑中容易出现混淆，数据语义不严谨，不建议用于有明确归属要求的场景。

总结：优先选择方案2，它兼顾了逻辑简洁性和查询效率，资源消耗可以忽略；如果完全不想存储冗余数据，再考虑方案1；绝对不要使用多对多关系，这会给系统带来不必要的复杂度和资源浪费。

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