附件表设计：外键关联 vs 存储附件ID分析

两种设计方案对比

1. 外键关联方案

CREATE TABLE articles (
    id INT PRIMARY KEY,
    title VARCHAR(255),
    content TEXT
);

CREATE TABLE attachments (
    id INT PRIMARY KEY,
    article_id INT,
    file_name VARCHAR(255),
    file_path VARCHAR(255),
    file_size INT,
    FOREIGN KEY (article_id) REFERENCES articles(id)
);

2. 存储附件ID方案

CREATE TABLE articles (
    id INT PRIMARY KEY,
    title VARCHAR(255),
    content TEXT,
    attachment_ids VARCHAR(255) -- 存储逗号分隔的附件ID
);

CREATE TABLE attachments (
    id INT PRIMARY KEY,
    file_name VARCHAR(255),
    file_path VARCHAR(255),
    file_size INT
);

优缺点分析

外键关联方案

优点： - 符合关系型数据库设计规范 - 数据完整性有保障（级联删除/更新） - 查询效率高（可使用JOIN操作） - 易于维护和扩展

缺点： - 需要额外的外键约束 - 删除文章时需要处理关联附件

存储附件ID方案

优点： - 实现简单 - 不需要外键约束 - 适合简单的应用场景

缺点： - 违反第一范式（1NF） - 无法保证数据完整性 - 查询效率低（需要额外解析字符串） - 难以维护（如删除附件时需要更新多个文章记录）

推荐方案

强烈推荐使用外键关联方案，原因如下：

1. 数据完整性：外键确保不会出现"孤儿"附件
2. 查询效率：JOIN操作比字符串解析高效得多
3. 可维护性：符合标准数据库设计规范
4. 扩展性：更容易支持复杂的查询需求

进阶优化建议

1. 考虑使用多对多关系（如果附件可被多篇文章共享）：

   CREATE TABLE article_attachment (
      article_id INT,
      attachment_id INT,
      PRIMARY KEY (article_id, attachment_id),
      FOREIGN KEY (article_id) REFERENCES articles(id),
      FOREIGN KEY (attachment_id) REFERENCES attachments(id)
   );
   

2. 考虑使用JSON类型存储元数据（现代数据库如MySQL 5.7+/PostgreSQL）：

   ALTER TABLE attachments ADD COLUMN metadata JSON;
   

3. 考虑文件存储策略：

   • 小文件可直接存数据库（BLOB）
   • 大文件建议存储路径，文件放文件系统或对象存储

结论

对于大多数应用场景，外键关联方案是最佳选择。只有在极端简单的应用且对数据完整性要求不高的情况下，才考虑存储附件ID的方案。