数据仓库 数据库 建模：关于业务主键和逻辑主键的取舍
by s00n([email protected])
关于这个问题网上已经有很多的讨论，现在综合这些讨论在加上自己众多建模及数据仓库工作中的经验给出以下分析及取舍建议，供各位同行参考：
一、业务的东西，是每一个做软件的最薄弱的，并且是最有可能受到客户影响的，也是最会引起问题的。
比如身份证，如果有系统的表用此做主键，其他众多表以此为外键，当身份证从15位升到18位时，
整个数系统的重构将是一个非常困难的工作。一个系统在维护的成本远大于开发的成本，所以要
充分考虑客户业务变更的需求,用户今天说不会变，而明天可能就变了,即使用户已经对需求
确认签字。这些都是不可预知的。
二、业务主键在存在主从关系时候，更新时不方便(这样你必须要检查从表，再处理主表)。
三、业务主键是复合型时，CRUD操作时不方便(比如要定位一条记录时必须传入复合的每个字段,
四、使用业务主键，基于源数据的质量问题，往往存在业务主键重复,对于源数据可控及数据量小的操作,业务主键重复还容易控制，而对于某些高度耦合的系统来说， 后果是不堪设想的。
五、数据仓库的表中的冗余字段不是很少而是大量的,增加逻辑主键并不是冗余的根源。
建议设计的基本原则（具体情况可能要具体分析）：
一、对于业务数据，最好采用逻辑主键;
二、对于业务复合主键有多个字段(>3?)，需要采用逻辑主键;
三、对于基础数据，基于多方面考虑，是可以采用业务主键的。这类表初始化以后数据不会经常发生改变。
四、取消业务主键后，在查询经常会用到的相关的业务字段建立INDEX，可以提高查询效率;
五、使用逻辑主键,表的业务数据唯一性由程序来检查控制，使业务数据重复这类脏数据控制在业务允许的范围;
六、业务数据的重复这类脏数据也可以通过分析结果数据得到;
七、业务数据的逻辑主键使用numeric自增长型，在迁移数据时，取消目标表的自增长，数据迁移完成后，再重建逻辑主键。
by s00n([email protected])
2004-10-28
本文地址：http://com.8s8s.com/it/it26144.htm