数据库设计评审

数据库null存储integer脚本扩展

序号

检查项目

通过

不通过

忽略

　

1

l        数据库设计是否满足软件设计的一般要求？

    注：数据库设计应该满足软件设计的一般要求。

　

　

　

2

l        数据库设计是否与其他设计内容一致？

     注：作为软件设计的一部分，数据库设计应该与其他设计内容保持一致。

　

　

　

3

l        设计是否充分考虑了新系统与现有系统的关系，与现有系统的接口是否被充分考虑？

    注：在数据库设计中应该充分考虑新系统与现有系统的关系，与现有系统的接口应被充分考虑。

　

　

　

4

l        如果基础数据的一部分来源于其他系统，那么是否有工具或方案实现快速导入？

    注：如果有必要，应该设计工具或者方案将来源于其他系统的数据快速导入数据库。

　

　

　

　

5

l        反规范化（违反3NF）的设计是否有明确的说明，理由是否充分？

注：反规范化的设计有时是必要的，但是要注明理由。通常的理由包括：

1、为了提高查询效率，在频繁查询但不频繁更新的表中增加冗余列；

2、为了提高查询效率，将大容量表作水平分割（分割行）或垂直分割（分割列）；

3、为了方便进行统计，引入派生列；

4、……

如无恰当理由，所有设计均应遵循3NF。

　

　

　

6

l        对反规范化（违反3NF）设计部分的数据完整性是否进行了充分的考虑？

注：反规范化的设计可能产生数据冗余，因此应该视具体情况建立一定的机制（如触发器、过程）保证反规范化数据的完整性。

　

　

　

7

l        孤立表的设计理由是否充分？

    注：设计中应该对孤立表的设计理由作出明确的说明。

　

　

　

8

l        为保证查询和更新效率，是否对大容量表(千万行以上或100列以上)作了必要的设计？

    注：通常在大容量表上采用的设计包括：

1、将大容量表设计成分区表；

2、将大容量表作水平分割（分割行）或垂直分割（分割列）；

3、……

　

　

　

9

l        是否避免深度超过三层的视图？

    注：为了保证效率，视图的深度一般不超过三层。可以建立临时表降低视图的深度。

　

　

　

　

10

l        是否遵循统一的命名规范？

注：对所有的数据库元素应该采用统一的命名规范。

　

　

　

11

l        表、列、视图、触发器、过程的注释是否完整？

   注：应在表和列上建立中文说明；应在复杂视图的脚本中增加注释；应在触发器和过程脚本中增加注释。

　

　

　

12

l        命名是否避免使用数据库的保留字？

    注：命名应绝对避免使用数据库的保留字。

　

　

　

13

l        数据类型是否存在溢出的可能？

    注：检查数据的逻辑取值范围是否超出数据的设计类型，重点检查integer,smallint,char型字段。

　

　

　

14

l        数据类型的长度是否保留了未来扩展的余量?

   注：数据类型应保留一定的扩展余量。由此产生的典型问题包括：电话号码升位、身份证升位、千年虫等。

　

　

　

15

l        在作为查询条件的列上是否建立了NOT NULL约束？如果没有，理由是否充分。

    注：如果把未建立not null约束的列作为查询条件，查询结果中往往会漏掉取值为 null 的列。

　

　

　

16

l        是否谨慎地使用日期型字段？

   注：外部输入或导入的日期应使用varchar型或char型字段。典型的问题是：如果有的日期精确到日，有的日期只精确到年，那么这些数据在日期型字段中得不到准确的记录。

　

　

　

　

17

l        主键是否采用系统生成的键？如果不是，理由是否充分。

   注：现在的设计越来越倾向于使用系统生成的键作为主键，而不使用带有业务含义的主键。由系统生成的主键字段通常包括：自增长列、序列、GUID。

　

　

　

18

l        是否尽量避免将可能变动的字段作为主键？

    注：如果不使用系统生成的键，那么应该避免将可能变动的键作为主键。

　

　

　

19

l        如果外键字段未建立NOT NULL约束，那么理由是否充分。

   注：外键字段要么引用关联表的主键，要么为空。如果置空的外键字段有确定的业务含义，那么最好将这样的“业务含义”定义在外键关联表中，并且在外键字段上建立not null约束。

　

　

　

20

l        是否尽量使用数据库的约束机制实现数据的完整性？

   注：应该尽量利用数据库的约束机制（例如键、非空、唯一、check、触发器等）——而不是应用程序，保证数据完整性。

 

 

 

　

21

l        索引是否正确地建立在查询操作频繁的表上?

    注：应将索引建立在查询操作频繁的表上。建立索引的常用原则还包括：

1、使索引最可能被用在where子句中；

2、查询时不应对索引列作函数运算，否则应建立函数索引；

3、在大型表上建立索引有可能降低查询效率，可以将大表分区后建立分区索引；

4、……

　

　

　

22

l        索引是否尽量避免建立在大容量字段上?

    注：应尽量避免将索引建立在 memo, lob 或大文本这样的大容量字段上。

　

　

　

23

l        索引是否避免建立在小型数据表（少于5个块）上？

    注：在小容量表上建立索引没有意义。

　

　

　

24

l        是否将索引建立在独立的表空间上？如果不是，理由是否充分。

    注：将索引建立在独立的表空间上能够提高查询效率。

　

　

　

　

25

l        是否依据一定的原则，恰当地划分了表空间

    注：划分表空间的一般原则包括：

1、将访问方式相同的字段（例如lob字段）存储在一起；

2、将系统数据和业务数据分开存储；

3、将数据和索引分开存储；

4、将频繁增长变化和相对静止的数据分开存储；

……

　

　

　

　

26

l        是否有系统级和程序级的用户、角色和权限的设计？

    注：应该在数据库系统级和应用程序级分别设计用户、角色和权限。

　

　

　

27

l        是否进行了必要的设计，保证应用程序的数据库连接参数（包括用户名、密码等）独立、安全？

   注：应用程序通过数据库连接参数访问数据库。数据库连接参数应分别独立于应用程序和业务数据库，密码应加密。数据库连接参数的独立性和安全性应在设计中体现。

　

　

　

28

l        是否建立了数据库的备份和恢复策略？

    注：应该建立数据库的备份和恢复策略。通常即可以使用数据库的功能实现，也可以用应用程序实现。

 

 

 

　

29

l        如果有移植的需求，那么是否对移植性作了充分的考虑？

    注：如果有移植需求，那么应该慎重使用函数、过程、触发器，并且要有单独的移植方案。

 

 

 

30

l        其他检查内容：