4.使用序列的问题及解决办法
4.1 如何保证业务逻辑约束
由于系统使用一个额外增加一个字段作为主键,因此没有为业务逻辑建立主键约束。比如在企业用户信息表中,要求企业中用户登录名必须唯一。一般在创建表时,以登录名作为主键,这个时候在数据库层自然的创建另一个主键唯一性约束。而现在没有使用登录名作为主键,那么就没有这个约束。解决办法:
一是在数据库层解决。可以为该表创建一个唯一(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) – 唯一索引
二是在应用端解决。也就是在应用中判断该列是否有重复值,然后根据判断结果来保证唯一性。
4.2为何主键采用非聚蔟方式
我们注意到,在之前的例子中,主键采用了NONCLUSTERED(非聚蔟)的索引方式。关于如何设计索引,不是本文的重点,在这里仅提供一个建立索引时采用聚蔟方式还是非聚蔟方式的一个一般原则:
动作描述 | 使用聚集索引 | 使用非聚集索引 |
列经常被分组排序 | √ | √ |
返回某范围内的数据 | √ | × |
一个或极少不同值 | × | × |
小数目的不同值 | √ | × |
大数目的不同值 | × | √ |
频繁更新的列 | × | √ |
外键列 | √ | √ |
主键列 | √ | √ |
频繁修改索引列 | × | √ |
作为非业务字段的主键列,是一个没有重复值的、基本不进行更新操作的列。并且,在SQL Server数据库中,聚蔟索引在一个表中只能有一个。因此,聚蔟索引非常重要,需要留给更重要的字段来使用。因此,对照上表和根据聚蔟索引的重要程度,在此处采用非聚蔟方式创建其索引。
5. 具体应用
采用这种主键设计方式,有诸多好处,这已经在前文说明。现在就以一个具体的应用来说明如何使用这个主键。
当前的应用系统基本上都已经采用B/S方式,尽管现在的网络速度已经有大幅度的提高,但是由于在WEB应用上用户数量众多、同时基本上所有的运算都集中在WEB应用服务器上,所以在WEB设计上更要考虑到性能的优化,以减少网络流量和对服务器的压力。最常见的一个应用就是列表方式展现时的分页方式。一般的,在数据量小的情况下,一般不会怎么注意这个问题,通常采用将数据完全取出,然后在WEB服务器上进行分页。但是,当数据量庞大时,这种方式就会导致速度降低,甚至根本不可用。所以,一般采用存储过程,在数据库端进行分页。下面就提供一个通用的分页存储过程SP_COMMON_PAGER:
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号

TechTarget
官方微博

TechTarget中国
相关推荐
-
Linux支持的引入 推动了SQL Server 2016集成服务的发展
随着SQL Server的不断发展,集成服务也在发生相应的变化。在最新的SSIS更新中,增加Linux支持和SQL Server 2016升级向导。
-
Notre Dame对云端SQL Server性能基准的探索实践
确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。
-
横向扩展SQL Server应用程序:提高工作负载的选项
SQL Server管理员面临的最大挑战之一就是扩展数据库以适应更为繁重的数据处理工作负载。然而事情越发复杂的是,虽然Microsoft提供了许多不同的SQL Server可扩展性选项,但它们并不都适合于每种情况。
-
五大技巧构建首个SQL Server容器
容器的世界庞大而复杂,使用者可能会感到困扰,这里我们将列出一些示例,以便引导您顺利完成SQL Server容器的创建和管理。