数据库设计时规则就那么重要吗？

看了听棠.Net的文章数据库设计之“有时不得不违背的第三范式” ，想起了一件事情。

本科毕业论文是在XX市第一人民医院HIS系统基础上做的。当时，我大概在项目组里面待了一年多的时间，这是一个庞大的系统，涉及到HIS的方方面面，医保、划价收费、药房药库、诊疗等等无所不包，采用Oracle 9i + C#开发，当然最后的结果让人遗憾，由于各方面的原因，系统开发了一半就停止了。我的毕业论文中涉及到了数据库的设计，导师看了以后说，这个地方是不符合数据库设计的一般规则的，最好不要在论文中出现，而我的导师正是这个项目的负责人之一，数据库设计中也凝聚有他的心血。所谓的数据库设计不符合一般规则的地方是这样的：由于系统的庞大，系统中的表实在是太多了，几百个也不算多吧，我们都知道系统中可能会有很多牵扯到业务的表征事物类别的表，比如诊疗项目类别、药剂类别、医保类别等等等等，这个项目中的类别表的数目就有几十个，一般情况下，应该为这些类别都分别建立一个表用于存储数据，数据结果无非是：类别编号、类别名称、禁用等，但是这样以来，开发人员就痛苦了，他们要面队的数据表就太多了。基于长期的开发经验，而且这些表的数据结构非常相似，我们只建了一个表来存储所有的这些类别，这个表称为“口径表”（呵呵，“口径”这个名称跟别人讲，别人是不太明白的，因为这是自己摸索出来的东西并命名的）。口径表的字段如下：口径类别、口径编号、口径名称、备注等。这样，开发人员在进行开发时只需要面队一个表征事物类别的表，压力降低了很多。当需要数据表关联时，只需要指定一个具体的“口径类别”然后再关联就可以了。

我找了一下原来的毕业论文，竟然找到了这一段，呵呵……

 

    ⑵ 因为医院信息系统中涉及到的信息量非常大，常规方法建立的口径表(即类别表，如民族、市县等)会非常多，造成开发上的难度增加，查询时需要的连接比较多也降低了查询的效率。为解决这个问题，在数据库中建立一个总的口径表HIS.KJ口径，将数据相对固定同时不是非常重要的口径表中的数据都放到HIS.KJ口径表中。HIS.KJ口径表的结构如下，见表3.1.2_1：

表3.1.2_1 HIS.KJ口径表结构

Name	Type	Nullable	Default	Comments
类别	VarChar2(50)			PK，系统的口径类别，如用法、单位等
编号	VarChar2(50)			PK，分类口径编号
名称	VarChar2(50)
拼音码	VarChar2(50)
五笔码	VarChar2(50)	√
自定义标志	Number(1)		1	标识是否为自定义，只有自定义可修改
备注	VarChar2(100)	√
Name：字段名称；Type：数据类型；Nullable：是否可为空；Default：默认值；Comments：注释

    HIS.KJ口径中的示例数据：

表3.1.2_2 HIS.KJ口径表示例数据

类别	编号	名称	拼音码	五笔码	自定义标志	备注
民族	01	汉族	HZ		0	可修改
民族	02	蒙古族	MGZ		0
民族	03	回族	HZ		0
血型	1	A	A		0	可添加
血型	2	B	B		0
血型	3	AB	AB		0
血型	4	O	O		0

 

    示例数据中，存储了两种口径：民族和血型，常规的设置是把这两种口径分别建表。而实际上目前HIS.KJ口径中存储了包括民族、血型、物资状态、申请状态等45种口径，假如没有HIS.KJ口径这个总口径表的话，数据库中表的数目会比现在多出45 – 1 = 44个，只是系统的口径就多得让人眩目，大大分散了开发人员的注意力，同时系统中对口径的维护也更加麻烦，不具通用性。

规则就真的那么重要吗？还有什么例子，欢迎大家探讨！