数据库结构设计要点

数据库结构设计要点

任何应用系统的高性能运行，最基本的是数据库结构的设计。数据库结构是整个应用系统的根基，如果结构设计不好，只在数据库的参数来优化恐怕也不理想。下面给出关于Oracle环境的数据库结构设计的一点介绍，希望指出的是，这里的内容仅作者本人的一些经验和体会，不是理论和方法。仅供Oracle应用开发人员参考。

§23.1 分析阶段的对表的理解

在系统需求分析阶段，一般需要有经验的系统分析员及编程人一起与用户进行交流。这个阶段主要是听用户对需求的描述。但是当我们对用户的需求有初步的了解后，就需要分析员将这些用户需求变为文档，即写出数据需求定义。

一般来说，对用户的复杂的表结构、表中再套小表这样的大表，需要将它们的数据之间理清，拆开成几个相互有关系的表结构。不要简单地将用户的表原封不动地进行转换。

§23.2 正确的主键字段的选择

选择主键字段的前提是，该列的值不能有重复，也不能空，这是基本的要求。此外，建议注意下面的问题：

●该列的值不能过长，比如不能使用单位名称作为主键；

●建议用字符型或数字型（整数）作为主键；

●不要用日期型，浮点型之类的字段作为主键；

●如果只用一个字段作为主键出现重复，可采用加校验位或选用两字段作为主键，但

不推荐用3个以上的字段作为主键。

§23.3 字段类型及长度的选择

对于一个表的字段来说，不同的设计者可能给出不同的类型，有时字段确实可以定义成不同的字段。在这方面，目前从理论上没有明确的限制和规定。因而许多人就认为字段的定义只要能满足用户的要求即可。其实对于一个要求很高且复杂的应用系统。定义字段可以说是一项值得认真考虑的技术问题。本人多年的应用设计和开发中的一点经验，仅供参考。

§23.3.1 如果能用字符型就不要用数字型

在许多地方，有一些字段你可以用数字型也可以用字符型，比如员工的身份证号，从表面看，它的内容全是数字。就由于它的表面特点，所以大多数人认为用数字类型是肯定的。其实我们想一下，身份证的每一位都有其特殊的意义，在数据的输入和查询中，都有一套严密的核查方法。比如最后一位表示男（1）或女（2）。当我们用字符型时，可以在输入中用

where substr(per_id,15,1)=’1’ or substr(per_id,15,1)=’2’来检查数据的正确性。如果采用数字这样的判断就不那么容易了。

另外，应该提醒许多新的Oracle使用的是，在Oracle里，字符型也能进行运算。如：

SQL> desc abc

名称空? 类型

----------------------------------------- -------- --------------------

NAME VARCHAR2(20)

SAL VARCHAR2(5)

COMM VARCHAR2(5)

TOT NUMBER(6)

SQL> select * from abc;

NAME SAL COMM TOT

-------------------- --------- ---------- ---------------

Jodan 2234 1000 0

Johan 2000 2000 3000

SQL> select sum(sal),sum(comm),sum(to_number(sal)+to_number(comm)) tot

2 from abc;

SUM(SAL) SUM(COMM) TOT

---------- ---------- ----------

3234 3000 6234

§23.3.2 相互产生运算的数字型字段长度和精度要一致

在字段定义中，除了要求数字型必须能容纳下以后可能变化的数据外，还需要注意的地方就是：凡是相互可能参加运算的字段，它们的长度及精度最好要一致。这样做，初看起来，好象有的数值小的字段很浪费空间，其实，不要担心空间浪费而专门考虑需要多少字节就够了的想法。因为如果数字型的字段长度和精度参差不齐，有可能在某些运算中产生不必要的错误结果。比如，我们可能用PRO*C来编程，当我们根据表中的数字字段定义变量时，C编译不会检查这些变量与表中字段的一致性关系。举例来说，在表中字段说明很大，在C语言中可以说明的很小，但是当你将表中的字段的数据取出放到变量时，C 语言并不提示任何错误，这样，如果我们不作任何转换就直接进行运算的话，可能出现另外的结果。

§23.3.2 不要为了节省空间而将字段的长度缩小或拆开

现在的存储硬件发展很快，不要将以前的教科书的一些过时的理论带到当前的应用设计中来。这里所说的是指，实际的用户需要就是字段的长度需要。比如，有人经常将日期分成三个字段来定义，可能写 nian char(2), 即两位的年； yue char(1), 即 1 位的月，ri char(2), 两位的日。这样在年份只能存放两位，2000年存为00，2001年存为01 ；而月份就不同了，设计者要求用户 1 月输入成 1， 2月输入成2 ,…而10月输入成a ；11月输入成b等。这样的设计好象节省了空间，其实也没有节省多少，一条记录节省2个字节，几千万条记录才节省才节省几十兆字节。这样做无形中增加了程序的处理时间。对于优化和将来的移植很不利。

§23.4 将LOB类型的字段与其它的类型分开

Oracle8I提供了许多可以用于存储大对象数据的类型，如LONG、LONG RAW等。从性能出发，建议在设计表结构时将这些大对象类型与其它的类型数据分开存储。比如职工的基本档案，档案上有职工的基本情况信息和照片，在设计最好将照这样的LONG RAW类型与职工基本信息分开。然后采用唯一关键字段进行连接。

§23.5 采用具有编码的设计方法

对于具有在多处被使用的值应采用编码来设计，如职工的单位名称，因为一个单位有多名职工，如果每个职工对应的记录都有单位名称的话，就出现所谓的冗余。编码一般有两种，除了前面提到的冗余以外，另外还考虑一些在应用中的使用的方便性的问题。比如银行的存款应用。可以考虑设计一个叫“交易代码”的代码，它表示分别表示“存入”、“取出”及“结息”。可以将该字段取名为：

tran_code char(1) check (tran_code=’1’or tran_code=’2’or tran_code=’3’) ,

在设计操作处理界时，只给操作操作者选择“存入”、“取出”或“结息”三种可能，这样可以避免让操作员直接输入字符所带来的不一致等的问题。