业务主键 Vs. 逻辑主键，到底用哪一个？

dingrong

我倾向于使用逻辑主键。业务主键在
1。存在主从关系时候，更新时不方便。
2。业务主键是复合型时，使用不方便。

vacuum

再来一段：
Identify字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。

vacuum

应该是SEQUENCE字段.

vacuum

关于业务主键 Vs. 逻辑主键 该用谁 的讨论,整理一下.
大家不认为逻辑主键有什么缺点吗？都用它吗？ 以下是我的引述：
--
1.They're not standard SQL. Most products have it but there's no consistent implementation.
2.They can't be updated. This violates the relational data model (not fatal, but not good either). Duplicates can be accidentally inserted (fatal).
3.They only create numeric values. GUID/NewID() are also numeric only, and are hard to read.
4.Numeric values are not meaningful in many tables, and adding them complicates relationships between other tables.
--
Problems such as supporting replication, merging, and a providing a limited number of unique values for a heavy transactional systems
--
SEQUENCE字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。
--
欢迎讨论.

iamweng

最初由 dingrong 发布
[B]我倾向于使用逻辑主键。业务主键在
1。存在主从关系时候，更新时不方便。
2。业务主键是复合型时，使用不方便。 [/B]

我也是这样想的，我也提过类似的问题，在我的设计中也是使用逻辑主键，但是曾和别人产生过激烈冲突。著名的溺水三千也是反对者，他认为小的数据库设计可以，但大的不行，我也不知道为什么。我的感觉是侧重设计的人往往用业务主键，侧重开发的人往往用逻辑主键。（在不违反业务的情况下）。另外，逻辑主键在业务查询时完全没用，而它却有索引，这种情况在大表上尤其不适合。

vacuum

up

xyj0323

对于这个问题应该没有明确的答案吧，这个和应用的场合和使用的人有很大的关系吧，在一些实时性的数据量大的场合还是用业务主键吧，要不然数据库表还要额外的增加一个字段，还要增加索引，这个无疑就增加了数据库的负担，影响了系统的性能。对于开发人员来讲，有时为了编程上的方便增加一个逻辑主键，这个如果出现在数据量不是很大的时候，应该没有什么不可以！

husthxd

关键问题在于业务需求是会变化的,今天的业务主键明天很可能就不是了.
而对于使用torque/hibernate等实现持久层的java应用是要求表必须有主键的.
这种情况下使用逻辑主键会方便很多.

ZALBB

我主张使用逻辑主键！

业务主键可以用做唯一键+非空来保证业务需求。
但在系统使用是，最好使用逻辑主键来建立关系。

因为：

主键必须保持稳定——不能更改主键的域。
主键必须简洁，不要包含过分的属性。
主键的值不便改变。

从这些要求看，逻辑主键更适合应用。

pushboy

最初由 ZALBB 发布
[B]我主张使用逻辑主键！

业务主键可以用做唯一键+非空来保证业务需求。
但在系统使用是，最好使用逻辑主键来建立关系。

因为：

主键必须保持稳定——不能更改主键的域。
主键必须简洁，不要包含过分的属性。
主键的值不便改变。

从这些要求看，逻辑主键更适合应用。 [/B]

我们一直用逻辑主键
如果是业务主键，在主从关联上不好做
而且，业务是可以被改变的，这样影响很大
在大的数据库中，逻辑主键的性能也很好