关于数据库的逻辑设计，是一个很广泛的问题。本文次要针对开发使用中遇到在MS SQL Server上进行表设计时，对表的主键设计应留意的问题以及相应的处理办法。

主键设计现状和问题

关于数据库表的主键设计，普通而言，是依据业务需求情况，以业务逻辑为基础，构成主键。

比如，销售时要记录销售情况，普通需求两个表，一个是销售单的概要描述，记录诸如销售单号、总金额一类的情况，另外一个表记录每种商品的数量和金额。对于第一个表（主表），通常我们以单据号为主键;对于商品销售的明细表（从表），我们就需求将主表的单据号也放入到商品的明细表中，使其关联起来构成主从关系。同时该单据号与商品的编码一同，构成明细表的联合主键。这只是普通情况，我们稍微将这个问题延伸一下：假如在明细中，我们每种商品又可能以不同的价格方式销售。有部分按折扣价格销售，有部分按正常价格销售。要记录这些情况，那么我们就需求第三个表。而这第三个表的主键就需求第一个表的单据号以及第二个表的商品号再加上本身需求的信息一同构成联合主键;又或者其他情况，在第一个主表中，本身就是以联合方式构成联合主键，那么也需求在从表中将主表的多个字段添加进来联合在一同构成本人的主键。

数据冗余存储：随着这种主从关系的延伸，数据库中需求反复存储的数据将变得越来越庞大。或者当主表本身就是联合主键时，就必须在从表中将所有的字段重新存储一次。

SQL复杂度添加：当存在多个字段的联合主键时，我们需求将主表的多个字段与子表的多个字段关联以获取满足某些条件的所有详细情况记录。

程序复杂度添加：可能需求传递多个参数。

效率降低：数据库系统需求判断更多的条件，SQL语句长度添加。同时，联合主键自动生成联合索引

WEB分页困难：由于是联合主键方式（对于多数的子表），那么在WEB页面上要进行分页处理时，在自关联时，难于处理。

处理方案

从上面，我们曾经看到现有结构存在着相当多的弊端，次要是导致程序复杂、效率降低并且不利于分页。

为处理上述问题，本文提出：当使用系统后台数据库表间存在主从关系时，数据库表额外添加一非业务字段作为主键，该字段为数值型;或者当该表需求在使用中进行分页查询时，也应考虑如此设计。普通地，我们也可以几乎为任何表添加一个与业务逻辑无关的字段作为该表的主键字段。

由于该字段要作为表的主键，那么其首要条件是要保证在该表中要具有独一性。同时，结合SQL Server数据库本身的特性，可以为其建立一个自增列：

但是，SQL Server中的自增列却存在一个比较尴尬的理想，那就是该字段一旦定义和使用，用户无法直接干涉该字段的值，完全由数据库系统本身控制：

完全数据库系统控制，用户无法修正值

在数据库的发布和订阅时，使用自增列会比较麻烦

恢复部分数据时，使用自增列会比较麻烦

该列的值必须在插入数据后才能获取

鉴于此，建议不以自增列的方式来定义，而是参考Oracle数据库系统中序列，在SQL Server系统中实现类似Oracle数据库系统序列功用。这个具体在下面的大节中引见。我们只需求按照普通字段的定义方式修正表定义为：