http://www.cnblogs.com/surfsky/archive/2009/11/06/1597242.html
首先先定义两个概念：
基础表：一般是维度表，如用户、部门、产品等基础信息表。
记录表：其它有依赖于基础表的表就暂且称之为记录表吧。
问题的提出：
若不做特殊处理，基础表数据的变动，会导致相关的记录表历史数据无法反映历史原貌。
如产品价格更改等，查某张历史订单，发现其产品信息已经不存在或者由新记录替代，已经不能如实反映历史状态。
可选解决方案：
（1）采用记录归档方式
步骤
新建归档记录表，原id字段有一个对应的name字段
新建和流转时都采用id字段
完成后将记录拷贝到归档记录表，并填充name字段
优点
基础表无需变动。归档逻辑清晰，字段清晰。
可以针对完成的单子做物理及索引上的查询优化
缺点
冗余程度高
查询时要区分历史表还是新表
（2）采用字段冗余方式
步骤
id和name字段都并存
新建时根据id自动填写name字段
流转时使用id字段
完成后使用name字段
优点
基础表无需变动。记录表冗余度低。
缺点
还是有字段冗余，对于多外键的表冗余度就大了
看起来表字段设计得很外行^_^
（3）基础表采用数据仓库式的历史表方案
步骤
基础表多两个字段： startdate，enddate
基础表不允许物理删除记录，删除时只是将enddate写为now
任何对基础表关键信息的变更都将新增一条记录，将老记录enddate设置为now，新记录startdate为now
优点
记录表无需变动
任何时间点的基础表数据都可以查询到
缺点
查询麻烦：任何和基础表关联的操作都必须用时间段表达式，不容易理解且代码繁杂。如：
查询当前的用户信息：where dmn_user.enddate = date '3000-12-31'
查询2009-01-01时的用户信息：where dmn_user.startdate >= date '2009-01-01' and dmn_user.enddate <= date '2009-01-01'
（4）基础表采用RowId＋Status方案
步骤
基础表都有以下字段： Id, RowId，Status。Id是可重复编号，RowId是自动创建且唯一主键，供它表关联。
基础表不允许物理删除记录，删除时只是将Status设置为“Deleted”
任何对关键信息的变更都将新增一条记录，将老记录status设置为old or deleted，新记录status为inuse or normal
优点
更改代价小，逻辑好理解
缺点
将所有关联到id的操作都迁移到rowid，调试有工作量（不过也是在允许范围内）
结论：
（1）这4种方案都有实际应用场合。
·方案一：常用于很严谨的场合，归档表只准插入查询，不允许任何更改。如历史订单、档案。
·方案二：这个方案其实很常用，是一种折衷的适当冗余的方案。但不太适合有很多外键的场合。
·方案三：常用于数据仓库，可以查询到任一时刻的历史信息（很强大），缺点就是对不便对id做查询优化，不适合OLTP类型的系统（个人看法）。
·方案四：可适用于各种场合。历史数据稳定，查询便利，且不影响性能。
（2）相对而言，方案四较为稳妥且实施便利，推荐之。
一家之言，欢迎讨论：）