如何基于Expires字段将请求状态设置为Expired？常用实现方案有哪些？

方案1：优先采用派生状态逻辑（无需存储Expired状态，无数据不一致风险） #

Expired状态本身是完全由Expires字段和当前时间计算得到的派生属性，单独存储反而会引入数据同步的冗余逻辑，绝大多数场景下不需要把它写入数据库。你可以直接调整实体类的实现：

• 保留枚举中的Expired选项，仅用于对外返回状态时使用，不映射到数据库持久化字段
• 新增计算属性动态返回真实状态：

public enum RequestStatus
{
   Active,
   Cancelled,
   Expired
}

public class SomethingRequest
{
    // 仅持久化Active、Cancelled两种状态
    public RequestStatus StoredStatus { get; set; }
    public DateTime Expires { get; set; }
    
    // 对外暴露的真实状态，不映射到数据库
    public RequestStatus Status
    {
        get
        {
            if (StoredStatus == RequestStatus.Cancelled) return RequestStatus.Cancelled;
            return Expires < DateTime.UtcNow ? RequestStatus.Expired : RequestStatus.Active;
        }
    }
}

• 查询过滤时直接使用Expires < DateTime.UtcNow条件即可，给Expires字段加索引后查询效率和按状态字段过滤几乎没有差异。

该方案优势是完全不需要额外的状态同步逻辑，不会出现数据不一致问题，维护成本极低，是这类场景的首选实现。

方案2：若确实需要持久化Expired状态的实现方式 #

如果有旧系统兼容、统计分析需要等明确的持久化需求，可以选择以下任意一种方式同步状态：

• 数据库定时任务：使用MySQL事件调度器、SQL Server代理作业等数据库自带的定时能力，定期执行批量更新语句，将所有StoredStatus = Active AND Expires < 当前时间的记录状态更新为Expired，执行频率可根据业务对状态精度的要求设置（从每分钟一次到每天一次都可）。
• 应用层定时任务：使用Hangfire、Quartz.NET等.NET生态的定时任务框架，在应用代码中实现批量更新逻辑，优势是逻辑可以纳入代码版本管理，无需维护数据库脚本。
• 访问时动态更新：每次读取请求数据时先判断是否到期，若到期则先更新状态再返回，适合请求访问频率较高、对状态实时性要求不高的场景，缺点是长期无人访问的记录状态会一直滞后。

不推荐使用数据库触发器实现，触发器逻辑隐蔽性高，后期排查问题、调整逻辑的成本很高。

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