版本管理结构分层

--------------------交互层--------------------

1. 所有信息整体保存
2. 每一部分信息独立保存

--------------------业务层--------------------

对“版本”一词的理解应该跟随用户视角，版本的相关规则应该根据业务特征确定。

1. 点状结构，数据表间的关联关系极少
2. 每保存一次增加一个版本

3. 每天增加一个版本

4. 星状结构，中心位置的数据表发散出很多关联表 1+N

5. N越大，选择精细化版本管理的价值越大

6. 业务呈现横向扩展

7. 链状结构，A - B - C - D

8. 链越长，业务越深

9. 图状结构

10. 实际上，很少纯粹的星状和链状，大多数时候是两者结合
11. 也可能业务前期的结构比较是清晰，发展过程中演进成图
12. 社交应用、LinkedIn，个人基本信息、工作经历、教育经历、相册、职位、行业、好友、公司基本信息等等

社交应用场景，100万用户，每个用户有50个好友，关系型数据库和图书局库的性能对比 深度 MySql执行时间 Neo4J执行时间 返回条目
2 0.016 0.01 ~2500 3 30.267 0.168 ~110000 4 1543.505 1.359 ~600000 5 未完成 2.132 ~800000

--------------------系统层--------------------

系统数据表 DataVersionSettings

• id // 自增
• contentModelId // 业务层数据表标识
• isEnabled // 是否启动版本管理功能
• dotCount // 版本号中小数点的个数
• maxVersionFrequency // 生成新版本的最大频率（次数/小时），若该值为6，则10分钟内的第二次更新将不生成新版本
• createdAt
• updatedAt

业务数据表

• version
• createdBy
• createdAt
• deletedAt

数据版本管理可能是一个产品买点，但有可能让我们陷入泥潭。 有一个新的思路可以考虑一下，从schema层面进行version化，再对外呈现。