你会发现PRIMARY KEY语句就在sku列的定义得后面。该语句在sku列中的表增加PK，这样既简单、速度又快。

　　但是，这种方法有一个内在的问题。SQL Server在数据库中创建PK，每个PK都有一个相应的名字。但是我们并不指定名称，SQL Server就弥补上了一个。PK_Products_30242045就是这种情况。这个名称基于表名和一些任意的数字。从表面上看来，这并不是一个很大的问题，但是如果你之后从该表中删除PK了呢？如果你适当改变对环境的掌握，那你首先还要为从服务器上摒弃这个键再在创建一个脚本。以前的测试证明了在摒弃这个键时其他洞悉都不会暂停，你只需要在产品上运行这个脚本。问题是如果你用这里的脚本创建了该表，PK在每台服务器上的名字就不一样了，并且你的脚本也会操作失败。
　
　　当你创建这个键的时候如何命名呢？你怎么命名你的键很多时候是由你决定，但是我们在第七章中提供了一些命名指南。这样我们用pk_product_sku命名我们的PK。我们建议的最佳方案就是用这种方式明确命名你所有的外键。我们用以下的脚本从sku列定义中清除PRIMARY KEY语句并在表定义的末尾增加一个CONSTRAINT语句。

　　最后一点但并不是最不重要的一点就是，如果该表已经存在了，你还会给主键增加什么呢？首先，你必须保证列中的数据符合主键规则。它不包括NULL，每个行也必须是唯一的。然后，用另一个简单的脚本就可以了。

　　等等，还有。在这里我们使用sku列很好，但是我们还要谈一下其他的PK选项。如果你检查整个数据库并在Products表上定义PK，那么你在每个表中得到的就是包括外键的不同的列名。这并不是一间坏事，但是它意味着如果你想增加含有外键的另一列或者需要写一些代码来连接表，你就必须查询数据类型和列名。

　　那么，如果你所有列表中的PK都有相同的名字不是一件好事吗？例如，数据库中的每个表都有一个叫objectid的列，并且该列仅有唯一的任意整数。在这种情况下，你就可以在SQL Server中用到识别列管理你的整数PK值。识别列就是自动在表中增加并插入数字的列。当你的创建了一个识别列（identity column），你就要指定seed、初始值和增量，这样每次新记录增加时它就是增量。最普遍的是，seed和增量都被设为1，就是说每个新的行都有同一值，也就是它要比之前的值要高1。

　　另一个任意的PK选项就似乎GUID。当你需要在数据库之间复制数据时，最通常的情况就就是用GUID作PK，你需要从其他数据库复制过来的数据和现有数据不相冲突。如果你改用恒等式，你就需要用seed值消除冲突，例如，1，000，454这个数字在两个数据库之间就很容易被用到，在复制数据时就出现了冲突。GUIDs的缺点就是它们比整数要大，并且人们不容易读懂。还有，PK经常是集群式的，就是说它们是按照顺序来存储的。由于GUID是任意的，每次你增加数据时，都会将数据插入到PK中间。这也增加了操作了额外负担。在第十章我们还将讨论集群式的PK和非集群式的PK。

　　我们已经讨论了所有的PK选项，最常见的情况就是我们使用的是恒等式列。它们很容易设置并提供了表之间的一贯性。不管你用的是什么方法，都要认真它的考虑优缺点。用错误的方法创建一个PK不仅会让你很难编写数据库代码，而且还会使性能降低。

　　外键

　　有了主键，外键在SQL Server中和在逻辑设置中的运行原理是一样的。外键就是和主键相应的并能建立关系的列或列组合。有相同的数据的列作为主键存在于外键中。正是如此我们才强烈强烈建议你不要用合成主键，这样不仅会给你带来大量的数据复制工作，而且还会在你连接表时增加额外的负担。回到刚才的employee和vehicle例子，它含有一些抽样资料的表。

　　图3.2 employee和 vehicle表显示表之间的关系

　　你能看出，这两个表都有objid列。identity列就是我们的主键。此外还要注意vehicle表有一个employee_objid列，该列中包含已经匹配了交通工具的员工的objid。在SQL Server中，vehicle表中设立了外键，它主要是用来保证你增加到employee_objid列中的值是有效值，并且在employee表中有相应值。