为公园表添加百余个枚举列替代关联表的潜在弊端咨询

1. 数据库结构僵化，扩展性差 #

即便目前所有筛选项都是预先定义的，后续要新增、修改或删除筛选选项时，都必须直接修改表结构（执行ALTER TABLE语句）。近百列的表，每次结构变更操作繁琐，且在数据量较大时，ALTER TABLE可能会锁表，阻塞线上查询请求，影响服务可用性。

2. 数据冗余与存储低效 #

每个布尔/枚举列仅存储是/否状态，多数公园的大量列值会是false或默认值，造成存储空间浪费。即便PostgreSQL对布尔类型存储有优化，当表数据量达到数十万甚至数百万条时，近百列的冗余存储问题会被显著放大。

3. 查询语句复杂且维护成本高 #

用户选择多个筛选条件时，SQL查询需要拼接大量AND column1 = true AND column2 = true ...的条件。筛选项越多，SQL语句越长，编写麻烦且后期维护（比如调整筛选逻辑、新增条件）时出错概率大幅提升，可读性和可维护性远不如标签关联表的查询写法。

4. 索引优化难度大 #

为提升多条件筛选的查询性能，可能需要为多列组合创建复合索引，但近百列的情况下，可能的组合数极多，无法为所有可能的筛选组合建索引。即便只针对常用组合建索引，也会导致索引数量过多，增加插入、更新公园数据的写入开销，同时占用更多磁盘空间。

5. 违反数据库设计范式 #

这种单表多列的设计违背了第一范式（1NF）——所有筛选项本质都是“公园特性”这一属性的不同取值，却被拆分为多个列存储。不符合范式的设计会提升数据一致性维护难度，比如后续若要将“露营”“野餐”归为“户外休闲”类别，这种结构几乎无法支持。

关于标签关联表多条件AND查询的解决方案 #

你之前遇到的多条件AND查询问题是可以解决的，以下是两种常用实现方式：

方式1：GROUP BY + HAVING #

SELECT p.*
FROM parks p
JOIN park_features pf ON p.id = pf.park_id
JOIN features f ON pf.feature_id = f.id
WHERE f.name IN ('露营', '海滩')
GROUP BY p.id
HAVING COUNT(DISTINCT f.id) = 2;

方式2：多EXISTS子查询 #

SELECT p.*
FROM parks p
WHERE EXISTS (
    SELECT 1 FROM park_features pf
    JOIN features f ON pf.feature_id = f.id
    WHERE pf.park_id = p.id AND f.name = '露营'
)
AND EXISTS (
    SELECT 1 FROM park_features pf
    JOIN features f ON pf.feature_id = f.id
    WHERE pf.park_id = p.id AND f.name = '海滩'
);

这两种方式都能高效实现多条件的AND筛选，且扩展性更好——新增特性只需在features表插入数据，无需修改表结构。

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