现有表启用System Versioning时，如何正确处理已有数据及默认约束风险？

一、当前处理方式的合理性 #

你的做法能让SQL语句执行成功，但并不完全符合系统版本控制的设计规范。GENERATED ALWAYS AS ROW START/END是SQL Server专为系统版本控制预留的列，本应由数据库自动维护，手动添加默认约束虽然能临时解决现有数据的列值填充问题，但后续可能引发逻辑冲突。

二、更优的实施流程 #

针对已有数据的表，推荐分阶段完成系统版本控制的启用，规避默认约束带来的隐患：

1. 添加系统版本控制列（允许为空）
   先添加带HIDDEN属性的列，避免干扰日常业务查询：

   ALTER TABLE [dbo].[User]
   ADD ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN,
       ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN,
       PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo);
   

2. 批量初始化现有数据的时间列
   给历史数据设置合理的初始时间（优先用业务数据的创建时间，无则用当前时间），注意ValidTo需设为SQL Server支持的最大时间值：

   UPDATE [dbo].[User]
   SET ValidFrom = GETDATE(),
       ValidTo = '9999-12-31 23:59:59.9999999';
   

3. 修改列属性为非空
   初始化完成后，锁定列的非空属性，确保后续数据完整性：

   ALTER TABLE [dbo].[User]
   ALTER COLUMN ValidFrom DATETIME2 NOT NULL;
   ALTER TABLE [dbo].[User]
   ALTER COLUMN ValidTo DATETIME2 NOT NULL;
   

4. 正式启用系统版本控制
   关联历史表（可让SQL自动创建，也可指定已存在的表）：

   ALTER TABLE [dbo].[User]
   SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = [dbo].[UserHistory]));
   

三、默认约束的风险说明 #

你提到的风险确实存在：

• 添加默认约束后，若手动插入数据时显式指定ValidFrom/ValidTo的值，会绕过SQL Server的自动维护逻辑，导致版本变更记录混乱。
• 用GETDATE()作为默认值，会让所有历史数据的初始时间统一为执行语句的时间，无法体现真实的业务数据创建时序，不利于后续的数据追溯。

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