《数据库结构设计要点.docVIP

数据库结构设计要点 任何应用系统的高性能运行，最基本的是数据库结构的设计。数据库结构是整个应用系统的根基，如果结构设计不好，只在数据库的参数来优化恐怕也不理想。下面给出关于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编译不会检查这些变量与表中字