如何优雅创建含嵌套外键的Article快照表ArticleArchive？

针对你提到的快照创建痛点（外键关联会随原数据变更、单张大表不够优雅），以下几个方案可以参考：

1. 结构化快照表组 #

保留原数据的关联结构，创建一组对应归档表，用统一标识绑定同一次快照的所有数据：

• ArticleArchive 表结构：

id [PK], 
archive_uuid [唯一非空], 
home, 
category, 
snapshot_at DATETIME, -- 快照生成时间
school, 
country

• UserArchive 表结构：

id [PK], 
archive_uuid [关联ArticleArchive的archive_uuid], 
original_user_id, -- 原用户ID，用于溯源
name

• LocationArchive 表结构：

id [PK], 
archive_uuid [关联ArticleArchive的archive_uuid], 
original_location_id, -- 原位置ID，用于溯源
address, 
name

优势：符合数据库范式，保留了原数据的关联逻辑，归档数据独立于原表，不会受原数据修改/删除影响；后续如果需要对归档的用户或位置数据做单独查询、统计，操作起来和原表一样方便。
适用场景：需要对快照的关联数据做精细化操作的业务场景。

2. JSON嵌套存储快照数据 #

如果业务上不需要对关联的User、Location数据做单独查询，只是需要完整的快照视图，可以把关联数据以JSON格式嵌入归档表：

• ArticleArchive 表结构：

id [PK], 
home, 
category, 
user_info JSON, -- 存储原User的{id: xxx, name: xxx}
location_info JSON, -- 存储原Location的{id: xxx, address: xxx, name: xxx}
snapshot_at DATETIME,
school, 
country

优势：表结构简单，一次查询就能获取完整的快照数据，实现成本低；不需要维护多表关联。
适用场景：快照仅用于整体查看、导出，不需要拆解关联数据做统计或筛选的场景。

3. 原表版本化改造 #

如果允许对原业务表做改造，可以通过版本号标记实现归档，无需单独创建归档表：

• 给Article表新增字段：version INT（自增版本号）、is_archived BOOLEAN（标记是否为归档版本）、archive_time DATETIME
• 给User和Location表新增字段：version INT、article_version INT（关联对应Article的版本号）、is_archived BOOLEAN
  每次需要归档时，复制当前Article、关联User/Location的数据，生成新的版本并标记为归档状态。
  优势：不需要额外维护归档表，所有版本数据统一管理；可以追溯原数据的所有变更历史。
  注意点：原表数据量会随版本增多而膨胀，需要做好索引优化和旧版本数据的清理策略（比如定期归档到冷存储）。
  适用场景：归档频率不高，且需要保留原数据完整版本历史的场景。

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