EF Core (C#)：如何在数据库中存储计算列Estimated

好的，针对你想把估算的Estimated值持久化到数据库、减少查询时计算量的需求，这里有几种实用的实现方案，你可以根据自己的技术栈和场景来选：

这种方式是在数据保存到数据库之前，主动计算好Estimated的值，再和其他字段一起存入。以EF Core为例：

• 先把实体类里的Estimated设为可持久化字段（不要加[NotMapped]标记），然后添加一个计算方法：

public class TimeEstimate
{
    public TimeSpan BestCase { get; set; }
    public TimeSpan MostLikely { get; set; }
    public TimeSpan WorstCase { get; set; }
    public TimeSpan Estimated { get; set; }

    // 手动触发计算的方法
    public void RefreshEstimated()
    {
        // 用Ticks计算避免TimeSpan直接运算的精度问题
        var totalTicks = BestCase.Ticks + 4 * MostLikely.Ticks + WorstCase.Ticks;
        Estimated = TimeSpan.FromTicks(totalTicks / 6);
    }
}

• 接着在DbContext的SaveChanges方法里重载，确保保存前自动计算：

public override int SaveChanges()
{
    // 找到所有新增或修改的TimeEstimate实体
    var targetEntities = ChangeTracker.Entries<TimeEstimate>()
        .Where(e => e.State is EntityState.Added or EntityState.Modified);
    
    foreach (var entry in targetEntities)
    {
        entry.Entity.RefreshEstimated();
    }
    return base.SaveChanges();
}

优点：逻辑都在应用层，调试和维护方便；数据库直接存储计算结果，查询时无需额外处理。
缺点：如果有外部程序直接通过SQL修改数据库表，Estimated值会失效，需要额外做约束。

直接在数据库表中创建持久化计算列，让数据库自动维护Estimated的值，应用层只需要读写三个基础字段即可。

以SQL Server为例，建表时可以这样定义：

CREATE TABLE TimeEstimates (
    Id INT PRIMARY KEY IDENTITY,
    BestCaseTicks BIGINT NOT NULL, -- 用Ticks存储TimeSpan，适配数据库无原生TimeSpan类型的情况
    MostLikelyTicks BIGINT NOT NULL,
    WorstCaseTicks BIGINT NOT NULL,
    -- PERSISTED关键字表示把计算结果存到磁盘，而非每次查询实时计算
    EstimatedTicks AS (BestCaseTicks + 4 * MostLikelyTicks + WorstCaseTicks) / 6 PERSISTED
)

然后在实体类里映射这个计算列：

public class TimeEstimate
{
    public int Id { get; set; }
    
    // 对外暴露TimeSpan属性，内部用Ticks字段映射数据库
    public TimeSpan BestCase 
    { 
        get => TimeSpan.FromTicks(BestCaseTicks); 
        set => BestCaseTicks = value.Ticks; 
    }
    public long BestCaseTicks { get; set; }
    
    // MostLikely和WorstCase同理
    public TimeSpan MostLikely { get; set; }
    public long MostLikelyTicks { get; set; }
    public TimeSpan WorstCase { get; set; }
    public long WorstCaseTicks { get; set; }
    
    // 标记为数据库计算生成，应用层只读
    [DatabaseGenerated(DatabaseGeneratedOption.Computed)]
    public TimeSpan Estimated 
    { 
        get => TimeSpan.FromTicks(EstimatedTicks); 
        private set => EstimatedTicks = value.Ticks; 
    }
    public long EstimatedTicks { get; set; }
}

优点：数据库自动维护值，不管数据从哪里修改都能保证一致性；查询时直接读取存储值，性能最优。
缺点：计算逻辑在数据库端，修改公式需要调整表结构；不同数据库的计算列语法略有差异（比如MySQL用GENERATED ALWAYS AS ... STORED）。

如果不能用计算列，可以创建触发器，在插入或更新数据时自动计算并更新Estimated字段。

以SQL Server为例：

CREATE TRIGGER trg_TimeEstimates_UpdateEstimated
ON TimeEstimates
AFTER INSERT, UPDATE
AS
BEGIN
    UPDATE te
    SET te.EstimatedTicks = (i.BestCaseTicks + 4 * i.MostLikelyTicks + i.WorstCaseTicks) / 6
    FROM TimeEstimates te
    INNER JOIN inserted i ON te.Id = i.Id
END

优点：不需要修改应用层逻辑，数据库端自动维护；能处理更复杂的计算场景。
缺点：增加数据库复杂度，调试和维护相对麻烦；触发器逻辑出错可能导致数据不一致。

• 数据库通常没有原生TimeSpan类型，建议用BIGINT存储TimeSpan.Ticks，应用层再转换，避免精度丢失。
• 若选应用层计算，要确保所有修改数据的入口都调用了计算方法，防止Estimated值不一致。
• 计算列的PERSISTED/STORED关键字一定要加，否则还是会每次查询实时计算，达不到减少计算量的目的。

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