经验总结：讲解大型数据库的设计准则

这篇文章重要先容了大型数据库设计所应把握的基础准则，具体内容请参考下文。

一个好的数据库产品不即是就有一个好的利用系统，假如不能设计一个公平的数据库模型，不仅会增加客户端和服务器段程序的编程和保护的难度，而且将会影响系统实际运行的性能。一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，由于数据量较小，设计职员和测试职员往往只留心到功效的实现，而很难留心到性能的单薄之处，等到系统投进实际运行一段时间后，才发明系统的性能在下降，这时再来考虑提高系统性能则要花费更多的人力物力，而全部系统也不可避免的形成了一个打补丁工程。笔者根据多年来设计和应用数据库的经验，提出以下一些设计准则，供同仁们参考。

命名的规范

---- 不同的数据库产品对对象的命名有不同的请求，因此，数据库中的各种对象的命名、后台程序的代码编写应采用大小写敏感的情势，各种对象命名长度不要超过30个字符，这样便于利用系统适应不同的数据库。

游标（Cursor）的慎用

---- 游标供给了对特定聚集中逐行扫描的手段，一般应用游标逐行遍历数据，根据取出的数据不同条件进行不同的把持。尤其对多表和大表定义的游标（大的数据聚集）循环很轻易使程序进进一个漫长的等特甚至逝世机，笔者在某市《住房公积金治理系统》进行日终帐户滚积数计息处理时，对一个10万个帐户的游标处理导致程序进进了一个无限期的等特（后经测算需48个小时才干完成）(硬件环境：Alpha/4000 128Mram ,Sco Unix,Sybase 11.0)，后根据不同的条件改成用不同的UPDATE语句得以在二十分钟之内完成。

以下为引用的内容：
示例如下：

Declare Mycursor cursor for select count_no from COUNT

Open Mycursor

Fetch Mycursor into @vcount_no

While (@@sqlstatus=0)

Begin

If @vcount_no=’’ 条件1

把持1

If @vcount_no=’’ 条件2

把持2

...

Fetch Mycursor into @vcount_no

End

改为

Update COUNT set 把持1 for 条件1

Update COUNT set 把持2 for 条件2

在有些场合，有时也非得应用游标，此时也可考虑将符合条件的数据行转进临时表中，再对临时表定义游标进行把持，可时性能得到明显提高。笔者在某地市〈电信收费系统〉数据库后台程序设计中，对一个表（3万行中符合条件的30多行数据）进行游标操

作(硬件环境：PC服务器，PII266 64Mram ,NT4.0 Ms Sqlserver 6.5)。 示例如下：

Create #tmp /* 定义临时表 */

( 字段1

字段2

...

)

Insert into #tmp select * from TOTAL where

条件 /* TOTAL中3万行 符合条件只有几十行 */

Declare Mycursor cursor for select * from #tmp

/*对临时表定义游标*/

...

索引(Index)的应用原则

---- 创立索引一般有以下两个目标：保护被索引列的唯一性和供给快速拜访表中数据的策略。大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的次序存储，一个表只答应有一个簇索引，因此，根据B树结构，可以懂得添加任何一种索引均能提高按索引列查询的速度，但会下降插进、更新、删除把持的性能，尤其是当填充因子（Fill Factor）较大时。所以对索引较多的表进行频繁的插进、更新、删除把持，建表和索引时因设置较小的填充因子，以便在各数据页中留下较多的自由空间，减少页分割及重新组织的工作。

数据的一致性和完整性

---- 为了保证数据库的一致性和完整性，设计职员往往会设计过多的表间关联（Relation），尽可能的下降数据的冗余。表间关联是一种强迫性措施，建立后，对父表（Parent Table）和子表(Child Table)的插进、更新、删除把持均要占用系统的开销，另外，最好不要用Identify 属性字段作为主键与子表关联。假如数据冗余低，数据的完整性轻易得到保证，但增加了表间连接查询的把持，为了提高系统的响应时间，公平的数据冗余也是必要的。应用规矩（Rule）和束缚（Check）来防止系统把持职员误输进造成数据的错误是设计职员的另一种常用手段，但是，不必要的规矩和束缚也会占用系统的不必要开销，需要留心的是，束缚对数据的有效性验证要比规矩快。所有这些，设计职员在设计阶段应根据系统把持的类型、频度加以均衡考虑。

事务的陷阱

---- 事务是在一次性完成的一组把持。固然这些把持是单个的把持，SQL Server能够保证这组把持要么全部都完成，要么一点都不做。正是大型数据库的这一特征，使得数据的完整性得到了极大的保证。

---- 众所周知，SQL Server为每个独立的SQL语句都供给了隐含的事务把持，使得每个DML的数据把持得以完整提交或回滚，但是SQL Server还供给了显式事务把持语句---- BEGIN TRANSACTION 开端一个事务

---- COMMIT TRANSACTION 提交一个事务

---- ROLLBACK TRANSACTION 回滚一个事务

---- 事务可以嵌套，可以通过全局变量@@trancount检索到连接的事务处理嵌套层次。需要加以特别留心并且极轻易使编程职员出错误的是，每个显示或隐含的事物开端都使得该变量加1，每个事务的提交使该变量减1，每个事务的回滚都会使得该变量置0，而只有当该变量为0时的事务提交（最后一个提交语句时），这时才把物理数据写进磁盘。

数据库性能调剂

---- 在盘算机硬件配置和网络设计断定的情况下，影响到利用系统性能的因素不过乎为数据库性能和客户端程序设计。而大多数数据库设计员采用两步法进行数据库设计：首先进行逻辑设计，而落后行物理设计。数据库逻辑设计往除了所有冗余数据，提高了数据吞吐速度，保证了数据的完整性，明白地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会下降，同时也提高了客 户端程序的编程难度，因此，物理设计需调和考虑，根据业务规矩，断定对关联表的数据量大小、数据项的拜访频度，对此类数据表频繁的关联查询应适当提高数据冗余设计。