Symfony 3下项目管理应用通用TimeLog实体数据库关联设计问询

我之前在做项目管理类系统的时候，刚好碰到过一模一样的需求——给各种不同实体做通用时间追踪，不想每次加新实体就改数据库结构。这里给你分享几个实际用过的方案和踩过的坑！

方案1：多态关联（最常用、最省心） #

这是业界处理这类“一对多关联多种实体”场景的标准方案，核心思路是在TimeLog表中存储两个字段：实体类型标识和实体ID，以此关联任意类型的实体。

数据库表结构示例 #

CREATE TABLE time_logs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL, -- 记录时间的用户ID
    duration INT NOT NULL, -- 追踪时长，比如按分钟存储
    description TEXT, -- 时间备注
    trackable_type VARCHAR(50) NOT NULL, -- 关联实体类型，比如'Ticket'/'Project'/'WikiPage'
    trackable_id INT NOT NULL, -- 对应实体的ID
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id),
    INDEX idx_trackable (trackable_type, trackable_id) -- 必须建复合索引提升查询性能
);

优缺点 #

• 优点：新增实体完全不用改数据库结构，只需要在业务模型层声明关联关系即可（比如Java/Hibernate用@Polymorphic、Python/Django用GenericForeignKey、Ruby on Rails用has_many :time_logs, as: :trackable）；开发效率极高，后期维护成本低。
• 缺点：数据库层面没有外键约束关联到具体实体表，可能出现trackable_id无效的脏数据（需要在业务层做校验）；部分数据库对多态查询的性能优化有限，所以复合索引一定要建。

方案2：枚举约束的中间表方式 #

如果你担心多态关联的类型字段会出现非法值，可以用中间表+枚举类型的方式，把实体类型限制在枚举范围内。

数据库表结构示例 #

-- 主时间日志表
CREATE TABLE time_logs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    duration INT NOT NULL,
    description TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

-- 关联中间表，用枚举限制实体类型
CREATE TABLE time_log_associations (
    id INT PRIMARY KEY AUTO_INCREMENT,
    time_log_id INT NOT NULL,
    entity_type ENUM('TICKET', 'PROJECT', 'WIKI_PAGE') NOT NULL,
    entity_id INT NOT NULL,
    FOREIGN KEY (time_log_id) REFERENCES time_logs(id),
    INDEX idx_entity (entity_type, entity_id)
);

优缺点 #

• 优点：枚举类型从数据库层面限制了允许的实体类型，避免脏数据；新增实体时只需要修改枚举值（比如ALTER TABLE time_log_associations MODIFY COLUMN entity_type ENUM('TICKET','PROJECT','WIKI_PAGE','NEW_ENTITY')），比改表结构简单。
• 缺点：查询时需要多关联一张表，逻辑稍微复杂一点；枚举值修改需要数据库操作，不像多态关联只改业务代码。

方案3：超类抽象（类表继承） #

如果你的所有可追踪实体有很多公共属性（比如创建时间、创建人），可以用类表继承的方式，先抽象出一个通用的可追踪实体超类，再让具体实体继承它，最后TimeLog直接关联这个超类。

数据库表结构示例 #

-- 可追踪实体超类表
CREATE TABLE trackable_entities (
    id INT PRIMARY KEY AUTO_INCREMENT,
    entity_type VARCHAR(50) NOT NULL, -- 标识具体实体类型
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    created_by INT NOT NULL,
    FOREIGN KEY (created_by) REFERENCES users(id)
);

-- 具体实体表，继承超类的ID
CREATE TABLE tickets (
    id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255) NOT NULL,
    status VARCHAR(20) NOT NULL,
    -- 其他Ticket专属字段
    FOREIGN KEY (id) REFERENCES trackable_entities(id)
);

CREATE TABLE projects (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    budget DECIMAL(10,2),
    -- 其他Project专属字段
    FOREIGN KEY (id) REFERENCES trackable_entities(id)
);

-- 时间日志表，直接关联超类
CREATE TABLE time_logs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    duration INT NOT NULL,
    description TEXT,
    trackable_entity_id INT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id),
    FOREIGN KEY (trackable_entity_id) REFERENCES trackable_entities(id)
);

优缺点 #

• 优点：数据库层面有完整的外键约束，数据一致性有保障；所有可追踪实体的公共逻辑可以放在超类里，代码复用性好。
• 缺点：架构复杂度高，需要调整现有实体的表结构；新增实体时需要继承超类，对现有系统的侵入性较强；查询具体实体的时间日志时需要多表关联，性能略低。

结合你的需求，优先推荐多态关联方案，理由如下：

• 完全符合你“新增实体不用改架构”的核心需求；
• 主流ORM框架都原生支持，开发成本极低；
• 只要在业务层做好“关联实体存在性校验”，就能避免脏数据问题。

如果对数据严谨性要求极高，再考虑枚举中间表方案；如果实体结构本身就很规整、有大量公共属性，才推荐类表继承方案。

额外提醒：不管用哪种方案，一定要给关联字段建复合索引（比如trackable_type + trackable_id），不然查询某个实体的所有时间日志时，性能会随着数据量增长急剧下降。

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