在主从关系的表设计中，子表也使用序列字段作为唯一主键，将父表的序列字段作为外键关联：
以下为引用的内容：
| create TABLE T_PK_DEMO_C ( U_ID BIGINT NOT NULL ,--唯一标识记录的ID COL_OTHER VARchar(20) NOT NULL ,--其他列 P_ID INT NOT NULL ,--父表ID CONSTRAINT PK_T_PK_DEMO_C PRIMARY KEY NONCLUSTERED (U_ID)--定义为主键 CONSTRAINT FK_T_PK_DEMO_C FOREIGN KEY (P_ID) REFERENCES T_PK_DEMO(U_ID) ON delete CASCADE, ) |
使用序列的问题及解决办法
由于系统使用一个额外增加一个字段作为主键，因此没有为业务逻辑建立主键约束。比如在企业用户信息表中，要求企业中用户登录名必须唯一。一般在创建表时，以登录名作为主键，这个时候在数据库层自然的创建另一个主键唯一性约束。而现在没有使用登录名作为主键，那么就没有这个约束。解决办法：
一是在数据库层解决。可以为该表创建一个唯一（UNIQUE）约束或者唯一索引。如：
alter TABLE T_PK_DEMO ADD CONSTRAINT C_T_PK_DEMO UNIQUE NONCLUSTERED(COL_OTHER)-唯一约束
create UNIQUE INDEX IX_T_PK_DEMO ON T_PK_DEMO(COL_OTHER) – 唯一索引
二是在应用端解决。也就是在应用中判断该列是否有重复值，然后根据判断结果来保证唯一性。
我们注意到，在之前的例子中，主键采用了NONCLUSTERED(非聚蔟)的索引方式。关于如何设计索引，不是本文的重点，在这里仅提供一个建立索引时采用聚蔟方式还是非聚蔟方式的一个一般原则：
作为非业务字段的主键列，是一个没有重复值的、基本不进行更新操作的列。并且，在SQL Server数据库中，聚蔟索引在一个表中只能有一个。因此，聚蔟索引非常重要，需要留给更重要的字段来使用。因此，对照上表和根据聚蔟索引的重要程度，在此处采用非聚蔟方式创建其索引。
具体应用
采用这种主键设计方式，有诸多好处，这已经在前文说明。现在就以一个具体的应用来说明如何使用这个主键。
当前的应用系统基本上都已经采用B/S方式，尽管现在的网络速度已经有大幅度的提高，但是由于在WEB应用上用户数量众多、同时基本上所有的运算都集中在WEB应用服务器上，所以在WEB设计上更要考虑到性能的优化，以减少网络流量和对服务器的压力。最常见的一个应用就是列表方式展现时的分页方式。一般的，在数据量小的情况下，一般不会怎么注意这个问题，通常采用将数据完全取出，然后在WEB服务器上进行分页。但是，当数据量庞大时，这种方式就会导致速度降低，甚至根本不可用。所以，一般采用存储过程，在数据库端进行分页。
