2023年7月27日发(作者：)

数据库设计中应注意的问题⼀、⼀个好的数据库设计⾸先要满⾜⽤户的需求所有信息系统最后都将提交给最终⽤户使⽤，对于这⼀点，相信⼤家都已经达成共识。但是准确地把握⽤户的需求是很难的，虽然各⽅⾯的专家已经从不同⽅⾯给出了解决⽅案，但是⽤户需求仍然是软件⼯程中最不确定的因素之⼀。⼆、⼀个好的数据库设计要便于维护和扩充为了应对⽤户需求的修改和添加，也为了满⾜各种不同的软硬件环境下系统的使⽤，⼤部分信息系统都不得不在其⽣命期中进⾏升级和调整。在这些升级、调整中，⼜有相当部分会涉及到数据库设计的修改，因此，数据库设计最好从⼀开始就能在易维护、可扩充的⾓度多加斟酌。1、不要为各种编号字段的设定固定的意义⽽是最好通过对照表来建⽴这种编号和意义的对照关系。举例来说，很多设计者习惯给部门信息给出固定的编号，这种设计有个致命的缺陷：那就是由于这种对照关系既然不体现在数据库中，就必然要⽤业务逻辑来进⾏解释，这样⼀来，⼀有新的调整就不得不更新业务逻辑代码，也就⾮常容易不⼀致的错误。2、枚举信息要体现在相应在对照表中⽽不是体现在使⽤该信息的表中的值字段，这样做的好处是当⽤户希望⽤该枚举信息作为查询条件的时候，通过参照表的⽅式可以很容易的建⽴这些信息，另外也避免了当多个表格中都含有该枚举信息有可能引起的不⼀致。3、⽤关联表建⽴表和表之间的多对多关系⽽不要⽤⼀个字段解析的⽅式进⾏，举例来说，为了描述⽤户(UserInfo)和⾓⾊(RoleInfo)之间的关联关系，我们要建⽴对照表UserInfo_RoleInfo，⽽不要试图在⽤户表中建⽴⼀个较长的字段，如Roles（⽤的形式构成）来代替，因为这样⼀来字段解释需要在业务代码相应的解析代码，⼆来由于Roles定长，⽆法满⾜⽤户⾓⾊的扩充。三、⼀个好的数据库设计要具有“可读性”如同编程书籍中反复强调的程序员⼀定要在代码的可读性⽅⾯下功夫⼀样，考虑到信息系统将来的升级和维护可能要要由另外⼀批⼈来进⾏，因此数据库设计必然也要具有可理解性。对此，我们参照提⾼代码可读性的常⽤⽅法，给出⼀些建议：1、⽤设计⽂档来提⾼数据库设计的可读性这点基本对应于“可读性”代码⾥⾯的注释。在⼀个合格的数据库设计⽂档中必须给出数据库中的每个表、每个字段、表间的关联关系以及各种约束的意义以及由来，从⽽有可能让开发者根据⽤户需求和设计⽂档就能理解正确数据库的设计。2、给表和视图起⼀个有意义的名字这点对应于coding规范中的变量和函数的命名，很显然，CustomerInfo的名字很容易联想到该表中含有客户信息，⽽把它命名为Table0001只能让⼈感到费解外。另外，如果DBMS提供表和视图名的⼤⼩写⽀持，该名称最好由每个构成单词（⾸字母⼤写）拼接⽽成。3、⽤前缀给出表和视图内容之外的其他信息如给参照表Ref_前缀，这样就可以让业务逻辑实现⼈员根据表的名字知道他所要操作的是不是张参照表，从⽽帮助他更快地理解详细设计，并有可能及早发现⾥⾯的错误。同样，给所有视图加上V_前缀，就可以让业务逻辑编程者很容易地知道他现在⾯临的是⼀个表还是视图，从⽽避免了对视图进⾏更新操作这种低级的错误。4、给每⼀个字段起⼀个有意义的名字如给CustomerInfo表中的电⼦邮件字段起名EMail让⼈很容易明⽩它的准确含义，⽽Field05则让⼈不知所云。基于同样的道理，数据库设计中也不能给字段起⼀个张冠李戴的名字。5、字段命名要考虑上下⽂举例来说，在UserInfo表中，⽤UserName来表⽰⽤户名字段就不如Name来的更加合适。这种情况画蛇添⾜的情况在对照表的设计中体现得尤为明显，如把部门对照表(Ref_Department)中的部门ID字段命名为DepartmentID，把部门名称字段命名为DepartmentName等等。6、视图的设计不要牵扯到其他视图与代码设计中函数调⽤最好不要嵌套过多层次相对应，为了便于数据库设计的阅读⼈能够很好地理解设计，视图最好直接建⽴在表上。7、同⼀表中的记录最好不要相互引⽤这种引⽤关系不仅让数据库设计的阅读⼈云⾥雾⾥，也不便于业务逻辑代码的编写。8、关联表的命名⽤关联的表名中间加下划线连接构成如学⽣(StudentInfo)和课程(CourseInfo)的关联表起名StudentInfo_CourseInfo。四、⼀个好的数据库设计能够满⾜空间和效率的要求对于⼀个信息系统来说，在实现⽤户需求的基础之上，保证⼀个较低的空间占⽤以及短的响应时间都是理智的客户所愿意看到的。那么在这⼀⽅⾯，数据库设计⼜要做些什么⼯作呢？1、使⽤varchar⽽不要使⽤char字段对于不定长信息如⽤户的简介信息，varchar的使⽤可以减少近⼀半的空间占⽤。当然这点不能⼀概⽽论，如⽤相应长度的char存储定长⽂本数据就⽐varchar来的合适。2、不要使⽤BLOB字段存放“⼤数据”BLOB字段诚如其名，本⾝是为存储⼆进制⼤数据⽽出现的，同样的道理也适⽤于某些DBMS所引⼊的TEXT字段。因为对于⼀般信息系统⽽⾔，最长的字段往往是⼀些描述⽂本信息，⽽DBMS对char/varchar的长度基本能满⾜这种需求。因此积极建议设计者对⼀些貌似很长的⽂本的最⼤允许长度进⾏确认，在此基础上参照DBMS中的开发⼿册来决定是否采⽤⼤字段。3、不要使⽤设计器缺省的字段长度这种做法⼀⽅⾯纵容了设计者对⽤户需求的⼀知半解以及对设计敷衍了事的不良习惯，另外⼀⽅⾯也在数据的存储上浪费了不少的空间，因为使⽤缺省字段长度的情况往往发⽣在字段上。4、不要轻易使⽤unicode⽂本字段DBMS对unicode的⽀持在帮助产品国际化的同时，也在⼀定程度上带来空间上的浪费，尤其是在当要存储的⽂本中的基本都是ASCII字符的情况下，这种浪费尤为明显。因此，建议设计者在选择unicode的理由，⼀定是出于国际化的考虑，⽽不是其他。因为⼤多数的⼤字符集和ASCII字符并存情况下所要碰到的问题基本上都已经由DBMS提供商解决。5、使⽤预计算表来提⾼响应速度跟数据仓库⾥⾯的某些思路相似，当业务逻辑中需要⽤倒根据历史信息得来的统计数据时，最好由独⽴于系统的预计算模块或相应的DW⼯具定期完成这些统计数据的预计算。五、⼀个好的数据库设计可以简化业务逻辑的设计所有的数据库设计都不是孤⽴的，它通过相应的业务逻辑实现（三层结构中还有表现层）来形成最终的产品，因此⼀个好的数据库设计应该能够帮助降低业务逻辑的编写难度，最起码不要给业务逻辑的设计、编码带来额外⼯作。1、所有允许为空的字段必须是基于⽤户需求，⽽不是出于设计上⽅便的考虑。这样带来的好处是让详细设计中的某些错误和疏漏（如在设计中没有考虑对⾮空字段的内容检查）在编码和单元测试阶段就被发现，从⽽避免了进⼀步扩散，有助于提⾼软件的质量。2、不要业务逻辑代码实现唯⼀性约束对数据库表中的某些字段（或者多个字段的组合）的唯⼀性约束应该尽可能地加到数据库端。因为这种约束⼯作交给业务逻辑中去实现代价⾼昂⽽且不可靠。3、关联约束⼀定要建⽴在数据库端分析出设计中所涉及的主外键引⽤关系并体现在数据库设计中。这⼀条出于两点考虑：降低业务逻辑的编写难度和数据关联性约束的要求。