嘿，这个问题我之前帮不少开发者梳理过，咱们一步步来拆解：

这里有两种常用且靠谱的方案，你可以根据自己的技术栈和业务需求选择：

方案1：带类型标识的外键关联（通用型） #

这是最直观、适配大多数场景的设计，核心是用两个字段明确附件的归属：

CREATE TABLE Attachment (
    id INT PRIMARY KEY AUTO_INCREMENT,
    file_name VARCHAR(255) NOT NULL, -- 原始文件名
    file_path VARCHAR(255) NOT NULL, -- 文件存储路径（或云存储的key）
    file_size BIGINT NOT NULL, -- 文件大小（字节）
    mime_type VARCHAR(100), -- 文件MIME类型，比如image/jpeg
    -- 核心关联字段
    parent_id INT NOT NULL, -- 关联Post或PrivateMessage的主键ID
    parent_type ENUM('post', 'private_message') NOT NULL, -- 标记归属类型
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP, -- 上传时间
    uploader_id INT NOT NULL, -- 可选：记录上传附件的用户ID
    -- 外键约束（假设存在Users表）
    FOREIGN KEY (uploader_id) REFERENCES Users(id)
);

举个例子：如果是帖子ID为123的附件，parent_id填123，parent_type填'post'；如果是私信ID为456的附件，parent_id填456，parent_type填'private_message'。查询时直接通过这两个字段过滤就行，比如：

-- 获取ID为123的帖子的所有附件
SELECT * FROM Attachment WHERE parent_id = 123 AND parent_type = 'post';

方案2：多态关联（ORM友好型） #

如果你用Laravel、Hibernate这类ORM框架，多态关联会让代码更简洁。结构和方案1类似，只是字段名更贴合ORM的约定：

CREATE TABLE Attachment (
    id INT PRIMARY KEY AUTO_INCREMENT,
    file_name VARCHAR(255) NOT NULL,
    file_path VARCHAR(255) NOT NULL,
    file_size BIGINT NOT NULL,
    mime_type VARCHAR(100),
    attachable_id INT NOT NULL, -- 关联的主键ID
    attachable_type VARCHAR(100) NOT NULL, -- 关联的实体类型，比如'posts'或'private_messages'
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    uploader_id INT NOT NULL,
    FOREIGN KEY (uploader_id) REFERENCES Users(id)
);

ORM会自动识别attachable_type对应的表/实体类，你在代码里直接通过$post->attachments就能拿到该帖子的所有附件，不用手动写类型判断。

你没贴出当前的设计，我给你几个关键校验点，对照着就能快速判断：

• 归属是否明确：有没有字段能清晰区分附件属于帖子还是私信？如果你的Attachment表没有类似parent_type的标识，或者用post_id和private_message_id两个外键但没加约束，很可能出现一个附件同时属于两个实体的混乱情况。
• 数据一致性：如果用双外键的设计，必须加约束确保同一附件只能关联一个实体（比如用CHECK (post_id IS NOT NULL XOR private_message_id IS NOT NULL)），否则会有数据冗余和一致性风险。
• 查询维护成本：查询某个帖子/私信的附件、统计用户上传的所有附件时，是否需要复杂的JOIN或者多条件判断？如果是的话，设计可能不够高效。

• 保留uploader_id：记录上传附件的用户，方便后续做权限校验、上传统计等。
• 完善元数据：file_size、mime_type这些字段能避免每次访问都去读取文件系统获取信息，提升查询性能。
• 考虑软删除：加个deleted_at字段，用软删除代替物理删除，方便保留历史记录。
• 索引优化：给parent_id + parent_type（或attachable_id + attachable_type）加联合索引，大幅提升关联查询的速度；给uploader_id加单独索引，方便按用户筛选附件。

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