数据库主键设计之思考
在我们的数据库设计中，不可逃避的就是数据库表的主键，可能有很多朋友没有深入思考过，主键的设计对整个数据库的设计影响很大，因此我们不得不要重视起来。
主键的必要性 :
有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。
主键的无意义性 ：
我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也代表可以作为主键。因此，我推荐是新设一个字段专门用为主键，此主键本身在业务逻辑上不体现，不具有实际意义。而这种主键在一定程序增加了复杂度，所以要视实际系统的规模大小而定，对于小项目，以后扩展不会很大的话，也查允许用实际唯一的字段作主键的。
主键的选择
我们现在在思考一下，应该采用什么来作表的主键比较合理，申明一下，主键的设计没有一个定论，各人有各人的方法，哪怕同一个，在不同的项目中，也会采用不同的主键设计原则。
第一：编号作主键
此方法就是采用实际业务中的唯一字段的“编号”作为主键设计，这在小型的项目中是推荐这样做的，因为这可以使项目比较简单化，但在使用中却可能带来一些麻烦，比如要进行“编号修改”时，可能要涉及到很多相关联的其他表，就象黎叔说的“后果很严重” ; 还有就是上面提到的“业务要求允许编号重复时”，我们再那么先知，都无法知道业务将会修改成什么 ?
第二：自动编号主键
这种方法也是很多朋友在使用的，就是新建一个 ID 字段，自动增长，非常方便也满足主键的原则，优点是：数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利 ; 数字型的，占用空间小，易排序，在程序中传递也方便 ; 如果通过非系统增加记录（比如手动录入，或是用其他工具直接在表里插入新记录，或老系统数据导入）时，非常方便，不用担心主键重复问题。
缺点：其实缺点也就是来自其优点，就是因为自动增长，在手动要插入指定 ID 的记录时会显得麻烦，尤其是当系统与其他系统集成时，需要数据导入时，很难保证原系统的 ID 不发生主键冲突（前提是老系统也是数字型的） ; 如果其他系统主键不是数字型那就麻烦更大了，会导致修改主键数据类型了，这也会导致其他相关表的修改，后果同样很严重 ; 就算其他系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个“ o ”(old)来表示这是老数据，那么自动增长的数字型又面临一个挑战。
第三： Max 加一
由于自动编号存在那些问题，所以有些朋友就采用自己生成，同样是数字型的，只是把自动增长去掉了，采用在 Insert 时，读取 Max 值后加一，这种方法可以避免自动编号的问题，但也存在一个效率问题，如果记录非常大的话，那么 Max() 也会影响效率的 ; 更严重的是并发性问题，如果同时有两人读到相同的 Max 后，加一后插入的 ID 值会重复，这已经是有经验教训的了。
第四：自制加一
考虑 Max 加一的效率后，有人采用自制加一，也就是建一个特别的表，字段为：表名，当前序列值。这样在往表中插入值时，先从此表中找到相应表的最大值后加一，进行插入，有人可能发现，也可能会存在并发处理，这个并发处理，我们可以采用 lock 线程的方式来避免，在生成此值的时，先 Lock ，取到值以后，再 unLock 出来，这样不会有两人同时生成了。这比 Max 加一的速度要快多了。但同样存在一个问题：在与其他系统集成时，脱离了系统中的生成方法后，很麻烦保证自制表中的最大值与导入后的保持一致，而且数字型都存在上面讲到的“ o ”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的，应该字符型主键可以应付很多我们意想不到的情况。
第五： GUID 主键
目前一个比较好的主键是采用 GUID ，当然我是推荐主键还是字符型的，但值由 GUID 生成， GUID 是可以自动生成，也可以程序生成，而且键值不可能重复，可以解决系统集成问题，几个系统的 GUID 值导到一起时，也不会发生重复，就算有“ o ”老数据也可以区分，而且效率很高，在 .NET 里可以直接使用 System.Guid.NewGuid() 进行生成，在 SQL 里也可以使用 NewID() 生成。优点是：
同 IDENTITY 列相比， uniqueidentifier 列可以通过 NewID() 函数提前得知新增加的行 ID ，为应用程序的后续处理提供了很大方便。
便于数据库移植，其它数据库中并不一定具有 IDENTITY 列，而 Guid 列可以作为字符型列转换到其它数据库中，同时将应用程序中产生的 GUID 值存入数据库，它不会对原有数据带来影响。
便于数据库初始化，如果应用程序要加载一些初始数据， IDENTITY 列的处理方式就比较麻烦，而 uniqueidentifier 列则无需任何处理，直接用 T-SQL 加载即可。
便于对某些对象或常量进行永久标识，如类的 ClassID ，对象的实例标识， UDDI 中的联系人、服务接口、 tModel 标识定义等。
缺点是：
GUID 值较长，不容易记忆和输入，而且这个值是随机、无顺序的
GUID 的值有 16 个字节，与其它那些诸如 4 字节的整数相比要相对大一些。这意味着如果在数据库中使用 uniqueidentifier 键，可能会带来两方面的消极影响：存储空间增大；索引时间较慢。
我也不是推荐 GUID 最好，其实在不同的情况，我们都可以采用上面的某一种方式，思考了一些利与弊，也方便大家在进行设计时参考。这些也只是我的一点思考而已，而且可能我知识面限制，会有一些误论在里面，希望大家有什么想法欢迎讨论。
我们在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。当然，其它字段可以辅助我们在执行这些操作时消除共享冲突，不过就不在这里讨论了。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致。所以数据库在设计时，主键起到了很重要的作用。
常见的数据库主键选取方式有：
- 自动增长字段
- 手动增长字段
- UniqueIdentifier
- “COMB（Combine）”类型
一、自动增长型字段
很多数据库设计者喜欢使用自动增长型字段，因为它使用简单。自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。如果使用SQL Server数据库的话，我们还可以在记录插入后使用 @@IDENTITY 全局变量获取系统分配的主键键值。
尽管自动增长型字段会省掉我们很多繁琐的工作，但使用它也存在潜在的问题，那就是在数据缓冲模式下，很难预先填写主键与外键的值。假设有两张表：
Order(
OrderID
, OrderDate)
OrderDetial(
OrderID, LineNum
, ProductID, Price)
Order表中的OrderID是自动增长型的字段。现在需要我们录入一张订单，包括在Order表中插入一条记录以及在OrderDetail表中插入若干条记录。因为Order表中的OrderID是自动增长型的字段，那么我们在记录正式插入到数据库之前无法事先得知它的取值，只有在更新后才能知道数据库为它分配的是什么值。这会造成以下矛盾发生：
首先，为了能在OrderDetail的OrderID字段中添入正确的值，必须先更新Order表以获取到系统为其分配的OrderID值，然后再用这个OrderID填充OrderDetail表。最后更新OderDetail表。但是，为了确保数据的一致性，Order与OrderDetail在更新时必须在事务保护下同时进行，即确保两表同时更行成功。 显然它们是相互矛盾的。（此处表述有错误。吕震宇 2005-6-15）
【补充2005-6-15】---------------------------------------------
听棠.NET指出：主档放在事务中提交时，通过
@@IDENTITY
就可以取到生成值的，因此可以传给明细当外键用，而且在事务发生错误回滚时，主档记录也会被回滚取消的。
吕震宇补充：使用自动增长字段会增加网络的roundTrip。尽管可以使用@@IDENTITY取得主键的值，但在更新过程中，不得不增加一次数据往返（以C/S结构为例）：
1、客户端发送开始事务命令
2、客户端提交主表更新
3、服务器返回@@IDENTITY
4、客户端根据返回的主键更新从表缓冲
5、客户端将从表提交服务器更新
6、客户端提交事务
在这里多了一次往返就会增加了事务处理的时间。降低并发性能。
如果不用自动增长型字段，将是以下情景：
1、客户端发送开始事务命令
2、客户端提交主表更新
3、客户端提交从表更新
4、客户端提交事务
因此我不赞成使用自动增长型字段作为主键与外键链接的纽带。
------------------------------------------------
除此之外，当我们需要在多个数据库间进行数据的复制时（SQL Server的数据分发、订阅机制允许我们进行库间的数据复制操作），自动增长型字段可能造成数据合并时的主键冲突。设想一个数据库中的Order表向另一个库中的Order表复制数据库时，OrderID到底该不该自动增长呢？
ADO.NET允许我们在DataSet中将某一个字段设置为自动增长型字段，但千万记住，这个自动增长字段仅仅是个占位符而已，当数据库进行更新时，数据库生成的值会自动取代ADO.NET分配的值。所以为了防止用户产生误解，建议大家将ADO.NET中的自动增长初始值以及增量都设置成-1。此外，在ADO.NET中，我们可以为两张表建立DataRelation，这样存在级联关系的两张表更新时，一张表更新后另外一张表对应键的值也会自动发生变化，这会大大减少了我们对存在级联关系的两表间更新时自动增长型字段带来的麻烦。
二、手动增长型字段
既然自动增长型字段会带来如此的麻烦，我们不妨考虑使用手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。还用上面的例子来说，这次我们新建一张表叫IntKey，包含两个字段，KeyName以及KeyValue。就像一个HashTable，给一个KeyName，就可以知道目前的KeyValue是什么，然后手工实现键值数据递增。在SQL Server中可以编写这样一个存储过程，让取键值的过程自动进行。代码如下：
CREATE
PROCEDURE
[
GetKey
]
@KeyName
char
(
10
),
@KeyValue
int
OUTPUT
AS
UPDATE
IntKey
SET
@KeyValue
=
KeyValue
=
KeyValue
+
1
WHERE
KeyName
=
@KeyName
GO
这样，通过调用存储过程，我们可以获得最新键值，确保不会出现重复。若将OrderID字段设置为手动增长型字段，我们的程序可以由以下几步来实现：首先调用存储过程，获得一个OrderID，然后使用这个OrderID填充Order表与OrderDetail表，最后在事务保护下对两表进行更新。
使用手动增长型字段作为主键在进行数据库间数据复制时，可以确保数据合并过程中不会出现键值冲突，只要我们为不同的数据库分配不同的主键取值段就行了。但是，使用手动增长型字段会增加网络的RoundTrip，我们必须通过增加一次数据库访问来获取当前主键键值，这会增加网络和数据库的负载，当处于一个低速或断开的网络环境中时，这种做法会有很大的弊端。同时，手工维护主键还要考虑并发冲突等种种因素，这更会增加系统的复杂程度。
三、使用UniqueIdentifier
SQL Server为我们提供了UniqueIdentifier数据类型，并提供了一个生成函数NEWID( )，使用NEWID( )可以生成一个唯一的UniqueIdentifier。UniqueIdentifier在数据库中占用16个字节，出现重复的概率非常小，以至于可以认为是0。我们经常从注册表中看到类似
{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}
的东西实际上就是一个UniqueIdentifier，Windows用它来做COM组件以及接口的标识，防止出现重复。在.NET里管UniqueIdentifier称之为GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一个GUID：
Guid u
=
System.Guid.NewGuid();
对于上面提到的Order与OrderDetail的程序，如果选用UniqueIdentifier作为主键的话，我们完全可以避免上面提到的增加网络RoundTrip的问题。通过程序直接生成GUID填充主键，不用考虑是否会出现重复。
UniqueIdentifier字段也存在严重的缺陷：首先，它的长度是16字节，是整数的4倍长，会占用大量存储空间。更为严重的是，UniqueIdentifier的生成毫无规律可言，要想在上面建立索引（绝大多数数据库在主键上都有索引）是一个非常耗时的操作。有人做过实验，插入同样的数据量，使用UniqueIdentifier型数据做主键要比使用Integer型数据慢，所以，出于效率考虑，尽可能避免使用UniqueIdentifier型数据库作为主键键值。
四、使用“COMB（Combine）”类型
既然上面三种主键类型选取策略都存在各自的缺点，那么到底有没有好的办法加以解决呢？答案是肯定的。通过使用COMB类型（数据库中没有COMB类型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中设计出来的），可以在三者之间找到一个很好的平衡点。
COMB数据类型的基本设计思路是这样的：既然UniqueIdentifier数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留UniqueIdentifier的前10个字节，用后6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与UniqueIdentifier组合起来，在保留UniqueIdentifier的唯一性的同时增加了有序性，以此来提高索引效率。也许有人会担心UniqueIdentifier减少到10字节会造成数据出现重复，其实不用担心，后6字节的时间精度可以达到1/300秒，两个COMB类型数据完全相同的可能性是在这1/300秒内生成的两个GUID前10个字节完全相同，这几乎是不可能的！在SQL Server中用SQL命令将这一思路实现出来便是：
DECLARE
@aGuid
UNIQUEIDENTIFIER
SET
@aGuid
=
CAST
(
CAST
(
NEWID
()
AS
BINARY
(
10
))
+
CAST
(
GETDATE
()
AS
BINARY
(
6
))
AS
UNIQUEIDENTIFIER
)
经过测试，使用COMB做主键比使用INT做主键，在检索、插入、更新、删除等操作上仍然显慢，但比Unidentifier类型要快上一些。关于测试数据可以参考我2004年7月21日的随笔。
除了使用存储过程实现COMB数据外，我们也可以使用C#生成COMB数据，这样所有主键生成工作可以在客户端完成。C#代码如下：
//
================================================================
///
<summary>
///
返回 GUID 用于数据库操作，特定的时间代码可以提高检索效率
///
</summary>
///
<returns>
COMB (GUID 与时间混合型) 类型 GUID 数据
</returns>
public
static
Guid NewComb()
{
byte
[] guidArray
=
System.Guid.NewGuid().ToByteArray();
DateTime baseDate
=
new
DateTime(
1900
,
1
,
1
);
DateTime now
=
DateTime.Now;
//
Get the days and milliseconds which will be used to build the byte string
TimeSpan days
=
new
TimeSpan(now.Ticks
-
baseDate.Ticks);
TimeSpan msecs
=
new
TimeSpan(now.Ticks
-
(
new
DateTime(now.Year, now.Month, now.Day).Ticks));
//
Convert to a byte array
//
Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333
byte
[] daysArray
=
BitConverter.GetBytes(days.Days);
byte
[] msecsArray
=
BitConverter.GetBytes((
long
)(msecs.TotalMilliseconds
/
3.333333
));
//
Reverse the bytes to match SQL Servers ordering
Array.Reverse(daysArray);
Array.Reverse(msecsArray);
//
Copy the bytes into the guid
Array.Copy(daysArray, daysArray.Length
-
2
, guidArray, guidArray.Length
-
6
,
2
);
Array.Copy(msecsArray, msecsArray.Length
-
4
, guidArray, guidArray.Length
-
4
,
4
);
return
new
System.Guid(guidArray);
}
//
================================================================
///
<summary>
///
从 SQL SERVER 返回的 GUID 中生成时间信息
///
</summary>
///
<param name="guid">
包含时间信息的 COMB
</param>
///
<returns>
时间
</returns>
public
static
DateTime GetDateFromComb(System.Guid guid)
{
DateTime baseDate
=
new
DateTime(
1900
,
1
,
1
);
byte
[] daysArray
=
new
byte
[
4
];
byte
[] msecsArray
=
new
byte
[
4
];
byte
[] guidArray
=
guid.ToByteArray();
//
Copy the date parts of the guid to the respective byte arrays.
Array.Copy(guidArray, guidArray.Length
-
6
, daysArray,
2
,
2
);
Array.Copy(guidArray, guidArray.Length
-
4
, msecsArray,
0
,
4
);
//
Reverse the arrays to put them into the appropriate order
Array.Reverse(daysArray);
Array.Reverse(msecsArray);
//
Convert the bytes to ints
int
days
=
BitConverter.ToInt32(daysArray,
0
);
int
msecs
=
BitConverter.ToInt32(msecsArray,
0
);
DateTime date
=
baseDate.AddDays(days);
date
=
date.AddMilliseconds(msecs
*
3.333333
);
return
date;
}
结语
数据库主键在数据库中占有重要地位。主键的选取策略决定了系统是否高效、易用。本文比较了四种主键选取策略的优缺点，并提供了相应的代码解决方案，希望对大家有所帮助。
