数据仓库数据库建模：关于业务主键和逻辑主键的取舍

本文作者s00n探讨了在数据仓库和数据库建模中，业务主键和逻辑主键的优缺点及取舍。指出业务主键可能因业务变化、更新不便、复合主键操作复杂、重复性问题带来挑战。建议通常采用逻辑主键，尤其是对于业务数据和复合主键情况。同时，对于基础数据，可以考虑使用业务主键，并强调了通过索引优化查询效率和程序控制数据唯一性的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

数据仓库数据库建模：关于业务主键和逻辑主键的取舍
                            by s00n(Jasea@sina.com)
       关于这个问题网上已经有很多的讨论，现在综合这些讨论在加上自己众多建模及数据仓库工作中的经验给出以下分析及取舍建议，供各位同行参考：
一、业务的东西，是每一个做软件的最薄弱的，并且是最有可能受到客户影响的，也是最会引起问题的。
    比如身份证，如果有系统的表用此做主键，其他众多表以此为外键，当身份证从15位升到18位时，
    整个数系统的重构将是一个非常困难的工作。一个系统在维护的成本远大于开发的成本，所以要
    充分考虑客户业务变更的需求,用户今天说不会变，而明天可能就变了,即使用户已经对需求
    确认签字。这些都是不可预知的。
二、业务主键在存在主从关系时候，更新时不方便(这样你必须要检查从表，再处理主表)。
三、业务主键是复合型时，CRUD操作时不方便(比如要定位一条记录时必须传入复合的每个字段,
四、使用业务主键，基于源数据的质量问题，往往存在业务主键重复,对于源数据可控及数据量小的操作,业务主键重复还容易控制，而对于某些高度耦合的系统来说，后果是不堪设想的。
五、数据仓库的表中的冗余字段不是很少而是大量的,增加逻辑主键并不是冗余的根源。