数据库中表设计原则分析.docVIP

数据库中表设计原则分析 　　摘要：文章指出，数据结构设计时任何一个应用系统运行的支撑，是整个应用系统的基础，在设计过程中结构设计存在缺陷，那么相对其进行调整只通过数据库的参数是远远不够的。通常来讲，需要清除用户复杂表的结构以及表中这样的表的大小，从而拆开几个有关系的表结构。不能单单将用户标原封不动地进行转换，这样的行为方式是非常不明智的。 中国论文网 /8/view-7222082.htm 　　关键词：数据库逻辑设计；表；主键；字段及类型 　　在Oracle应用中，除了影响性能的大都是系统的配置参数等原因外，影响应用系统性能的另一个原因是应用程序的编写不当。因而，调整应用程序也是改善性能的一个方面。 　　在对系统分析这个阶段中，需要有工作经验的分析员以及编程人员跟客户一起讨论商量。这个过程所需要做的工作就是聆听客户的需求。当全面理解客户的初步需求之后，就需要分析员将客户的这些需求以文档的形式进行归档，即是将数据的需求定义编写。然后根据E R图进行逻辑设计。设计应尽量遵循如下原则。 　　1主键字段的正确选择 　　在对主键字段选择的时候，对其要求是非常重视的，要求其不能有重复的值现象发生，对于留空的一定要杜绝发生，这是主键选段的最基础的要求。在这过程中还需要注意以下几个方面内容：（1）主键的选择不能采用单位形式，不能过长的采用列值。（2）主键的选择建议采用字符或者数型。（3）不能使用类似日期、浮点之类的形式。（4）使用过程中出现主键重复，那么可以选择2个字段作主键，但是不推荐使用3个以上作为主键。 　　2字段类型以及长度的选择 　　在设计的过程中，每个设计者的思维是不同的，在一个字段的表示上，不同的设计者给出的结果是不相同的，有时候定义的字段其实际意义各不相同。在这个程度上，目前的理论内容还没有完全给出一个定义来定义这种现象，所以，众多人表示只要字段能够满足客户要求就行。其实面对一个比较复杂的应用系统，在定义字段过程中需要考虑的变化因素是众多的。笔者经过多年实际工作经验对应用以及设计进行分析，以供同行参考。 　　2.1如果能用字符型就不要用数字型 　　在设计过程，有很多的地方、很多字段都是可以用字符型以及数字型进行表示，例如，工作员的身份证号。其内容基本上都是以数字组成。身份证的每一个部位都包含特殊的含义，其在输入以及查询的过程中都会有一套严密的核查方法。例如：最后一位表示男（1）或女（2）。当用字符型时，可以在输入中用where substr（per_id，15，1）=l’orsubstr（per_id，15，1）=2’来检查数据的正确性。如果采用数字这样的判断就不那么容易了。 　　2.2运算过程需求一致 　　在定义字段的过程中，除了要求数字型能够容纳日后也许变化的数据之外，还有一部分内容是值得重视的，即在可能参加运算的字段中，其长度和精度必须是保持一致的。 　　这样的处理方法，看上去会在一定程度上浪费空间，但是，没有必要去担心空间的使用程度，因为，假设其长度以及精度相差不齐，那么在运算过程中容易有算错的结果出现。 　　例如，可以采取PRO*C进行编程工作。当表内的数字字段的定义发生变量的时候，C编译不会去检查其中一致性的关系。举个例子说明：在表里面字段显得大，而在C语言中能够说明其小，当将表中的字段取出放到表量的过程中，语言没有提示错误的现象发生。在不经过任何转换的形式下进行运算，就会有不同的结果产生。 　　2.3不能为节省空间随意拆开字节 　　随着科技的迅猛发展，目前的储存硬件的发展进步是相当快的，在当前的应用设计阶段不要讲以往教科书里面的理论带到现在的环境中。这里所说的是指，实际的用户需要就是字段的长度需要。比如，有人经常将日期分成3个字段来定义，可能写nian char（2），即2位的年；yue char（1）即1位的月，ri char（2），2位的日。这样在年份只能存放2位，2000年存为00，2001年存为01；而月份就不同了，设计者要求用户1月输入成1，2月输入成2，…而10月输入成a；11月输入成b等。 　　这种设计形式好像节省了很多的空间，但实际上也没有节省多少，一条记录节省的也就是2个字节，那么成千上万条的记录也不过节省几十兆字节而己，这样的处理方式只会给程序的处理增加时间，对于优化和未来的移植是起到阻碍作用的。 　　2.4将LOB类型的字段与其它的类型分开 　　Oracle8i提供了许多可以用于存储大对象数据的类型，如LONG，LONG RAW等。从性能的角度考虑出发，建议在设计表格的时候将那些相对较大的对象跟其他种类的数据分开储存。比如职工的档案证件这些东西，职工档案其内容包含有一些关于职工的基本情况、相片之类的东西，在设计过程需要将这些信息与职工的信息进行分割，最后采