1. 序言
当前,随着信息量的急剧增加,对于数据的存储和管理方式,各企业都逐渐摆脱了之前的依靠文件系统(文本文件或者Excel)或者一些桌面型的小型数据库系统(如Access、FoxBASE或者DBase)的状态,转而通过一些大型数据库来管理企业的信息。这些大型数据库系统包括Oracle、MS SQL Server或者IBM DB2。尽管目前数据库系统也在向面向对象的数据库系统方向发展,但是上述的传统的关系型数据库系统依然占据着主要位置。
笔者从九十年代末开始以关系型数据库系统为基础为客户进行管理软件的定制化开发。主要是以PowerBuilder为前台开发工具,开发出一些列的C/S结构的软件。进入到本世纪,尤其是最近两年,笔者又以Visual Studio 2003为工具,开发了一些B/S结构的应用。但是,无论是使用何种开发工具,还是开发何种结构的软件,其后台数据库系统依旧是关系型数据库系统。根据客户的应用环境,主要是在MS SQL Server数据库上进行开发,当然也有基于Oracle数据库的软件开发。
也正是因为数据量信息量的增加,采用大型的关系型数据库系统作为企业的数据存储管理方式,也就要求基于数据库开发的开发者在数据库设计时必须遵循相应的规范。关于数据库逻辑设计,最重要的就是数据库表的设计,都有一套相应的理论支持,比如要满足相应的范式要求。一般而言,数据库表设计满足第二或者第三范式即可。
在开发过程中,也尽量遵循这些相应的规则,但由于之前的经验所限或者是在详细设计时做的工作不够充分,导致一些表结构不是很合理。正是这些不合理,目前出现一些问题,并且已经在部分系统中有所体现。
关于数据库的逻辑设计,是一个很广泛的问题。本文主要针对笔者开发应用中的现状,论述在MS SQL Server上进行表设计时,对表的主键设计应注意的问题以及相应的解决办法。
2.主键设计现状和问题
2.1 现状
关于数据库表的主键设计,一般而言,是根据业务需求情况,以业务逻辑为基础,形成主键。
比如,销售时要记录销售情况,一般需要两个表,一个是销售单的概要描述,记录诸如销售单号、总金额一类的情况,另外一个表记录每种商品的数量和金额。对于第一个表(主表),通常我们以单据号为主键;对于商品销售的明细表(从表),我们就需要将主表的单据号也放入到商品的明细表中,使其关联起来形成主从关系。同时该单据号与商品的编码一起,形成明细表的联合主键。这只是一般情况,我们稍微将这个问题延伸一下:假如在明细中,我们每种商品又可能以不同的价格方式销售。有部分按折扣价格销售,有部分按正常价格销售。要记录这些情况,那么我们就需要第三个表。而这第三个表的主键就需要第一个表的单据号以及第二个表的商品号再加上自身需要的信息一起构成联合主键;又或者其他情况,在第一个主表中,本身就是以联合方式构成联合主键,那么也需要在从表中将主表的多个字段添加进来联合在一起形成自己的主键。
笔者在以前的项目中,也基本上是采取这样的表设计思路来设计系统的表结构和主键。
2.2 存在的问题
在上面小节中,我们描述了当前在表的主键设计时的现状。从中我们不难看出存在这样的问题:
数据冗余存储:随着这种主从关系的延伸,数据库中需要重复存储的数据将变得越来越庞大。或者当主表本身就是联合主键时,就必须在从表中将所有的字段重新存储一次。
SQL复杂度增加:当存在多个字段的联合主键时,我们需要将主表的多个字段与子表的多个字段关联以获取满足某些条件的所有详细情况记录。
程序复杂度增加:可能需要传递多个参数。
效率降低:数据库系统需要判断更多的条件,SQL语句长度增加。同时,联合主键自动生成联合索引
WEB分页困难:由于是联合主键方式(对于多数的子表),那么在WEB页面上要进行分页处理时,在自关联时,难于处理。