PostgreSQL数据库设计：数组字段与分表方案的最佳实践选择

用ArrayField存储的适用场景 #

• 当artists和songs仅属于当前这条主数据，不会被其他主数据复用，比如这是某场专属演出的艺人、曲目，不存在其他演出关联同一批艺人/歌曲的情况
• 不需要对artists或songs做单独的查询、统计，比如从来不用查“包含某艺人的所有演出”“某首歌被哪些演出使用”这类需求
• 数据量小，数组元素不会频繁新增、删除，维护成本低

这种情况下用PostgreSQL的ArrayField完全可行，虽然严格来说违反1NF，但PostgreSQL对数组的支持成熟，查询也便捷（比如用ANY操作符匹配元素），开发效率高，单表查询性能也不错。

用关联表存储的适用场景 #

• 当artists或songs是可复用的实体，比如同一个艺人会出现在多场演出里，同一首歌会被多场演出使用，此时必须拆成关联表，避免数据冗余
• 需要对artists或songs做独立的业务扩展，比如要给艺人添加国籍、流派信息，给歌曲添加时长、专辑信息，单独的表能灵活扩展更多字段
• 有复杂查询需求，比如统计某艺人的演出次数、某首歌的出场频率，关联表的JOIN查询比数组的模糊匹配更高效、灵活

关联表示例结构 #

主表（以演出为例，命名为performances）：

CREATE TABLE performances (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    location VARCHAR(255) NOT NULL,
    image_url VARCHAR(255)
);

艺人关联中间表（performance_artists）：

CREATE TABLE performance_artists (
    performance_id INT REFERENCES performances(id),
    artist_name VARCHAR(255) NOT NULL,
    PRIMARY KEY (performance_id, artist_name)
);

歌曲关联中间表（performance_songs）：

CREATE TABLE performance_songs (
    performance_id INT REFERENCES performances(id),
    song_name VARCHAR(255) NOT NULL,
    PRIMARY KEY (performance_id, song_name)
);

如果艺人或歌曲本身需要更多属性，还可以单独建立artists和songs主表，再通过外键关联到中间表。

总结 #

没有绝对的“最佳实践”，核心看业务需求：

• 简单场景、无复用需求、无复杂查询：选ArrayField，快速落地
• 有实体复用、需要扩展属性、复杂查询：选关联表，符合规范化设计，扩展性更强

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