数据库设计的几个建议

本文导读：数据库设计是信息系统设计的基础，一个好的数据库设计在知足了软件需求以外，还要易维护、易扩充等等要求，还要考虑到数据的一致性、冗余性、访问效率，数据库设计包括：库的设计，表的设计，字段的设计，主键和外键的设计，索引设计，约束设计等等，下面介绍数据库设计的几个建议

1、通常好的数据库设计须要注意如下几点

 

一、一个好的数据库设计首先要知足用户的需求

全部信息系统最后都将提交给最终用户使用，对于这一点，相信你们都已经达成共识。可是准确地把握用户的需求是很难的，虽然各方面的专家已经从不一样方面给出了解决方案，可是用户需求仍然是软件工程中最不肯定的因素之一。

 

二、一个好的数据库设计要便于维护和扩充

为了应对用户需求的修改和添加，也为了知足各类不一样的软硬件环境下系统的使用，大部分信息系统都不得不在其生命期中进行升级和调整。在这些升级、调整中，又有至关部分会涉及到数据库设计的修改，所以，数据库设计最好从一开始就能在易维护、可扩充的角度多加斟酌。

 

（1）、不要为各类编号字段的设定固定的意义

而是最好经过对照表来创建这种编号和意义的对照关系。举例来讲，不少设计者习惯给部门信息给出固定的编号，这种设计有个致命的缺陷：那就是因为这种对照关系既然不体如今数据库中，就必然要用业务逻辑来进行解释，这样一来，一有新的调整就不得不更新业务逻辑代码，也就很是容易不一致的错误。

 

（2）、枚举信息要体如今相应在对照表中
 

而不是体如今使用该信息的表中的值字段，这样作的好处是当用户但愿用该枚举信息做为查询条件的时候，经过参照表的方式能够很容易的创建这些信息，另外也避免了当多个表格中都含有该枚举信息有可能引发的不一致。

 

三、用关联表创建表和表之间的多对多关系
 

而不要用一个字段解析的方式进行，举例来讲，为了描述用户(UserInfo)和角色(RoleInfo)之间的关联关系，咱们要创建对照表UserInfo_RoleInfo，而不要试图在用户表中创建一个较长的字段，如Roles（用RoleID1; RoleID2...的形式构成）来代替，由于这样一来字段解释须要在业务代码相应的解析代码，二来因为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）、关联约束必定要创建在数据库端
 

分析出设计中所涉及的主外键引用关系并体如今数据库设计中。这一条出于两点考虑：下降业务逻辑的编写难度和数据关联性约束的要求。

 

 

2、数据库设计的几个建议

 

1.使用明确、统一的标明和列名，例如 School, SchoolCourse, CourceID。
2.数据表名使用单数而不是复数，例如 StudentCourse，而不是StudentCourses。
3.数据表名不要使用空格。
4.数据表名不要使用没必要要的前缀或者后缀，例如使用School，而不是TblSchool，或者SchoolTable等等。

5.数据库中的密码要加密，到应用中再解密。 （其实就是散列存储、单向加密）
6.使用整数做为ID字段，也许如今没有这个必要，可是未来须要，例如关联表，索引等等。
7.使用整数字段作索引，不然会带来很大的性能问题 。
8.使用 bit 做为布尔字段，使用整数或者varcha是浪费。同时，这类字段应该以“Is”开头。
 

9.要通过认证才能访问数据库，不要给每个用户管理员权限。
10.尽可能避免使用“select *”，而使用“select [required_column_list]”以得到更好的性能。

11.假如程序代码比较复杂，使用ORM框架，例如hibernate，iBatis。ORM框架的性能问题能够经过详细的配置去解决。
12.分割不常使用的数据表到不一样的物理存储以得到更好的性能。
13.对于关键数据库，使用安全备份系统，例如集群，同步等等。
14.使用外键，非空等限制来保证数据的完整性，不要把全部的东西都扔给程序。
15.缺少数据库文档是致命的。你应该为你的数据库设计写文档，包括触发器、存储过程和其余脚本。
 

16.对于常用的查询和大型数据表，要使用索引。数据分析工具能够帮助你决定如何创建索引。17.数据库服务器和网页服务器应该放在不一样的机器上。这回提升安全性，并减轻CPU压力。18.Image和blob字段不该该定义在经常使用的数据表中，不然会影响性能。19.范式（Normalization）要按照要求使用以提升性能。Normalization作的不够会致使数据冗余，而过分Normalization 会致使太多的join和数据表，这两种状况都会影响性能。20.多花点时间在数据库设计上，不然你未来会付出加倍的时间来偿还