orcal数据库技巧和注意事项

五个经验 

经验一：在设计大型数据库时，把允许NULL的列放在表的后面。

　　在数据库表设计过程中，有些字段要求必须为非空，如表的关键字，单据编号字段等等。在数据库表创建的时候，往往需要把这些字段设置为非空。如此的话，就可以强制用户输入数据，以增强数据的一致性。

　　同时，在一张表中，也会有不少的字段，如员工信息表中，员工爱好、注释等字段，就可能允许为空。利用数据库专业术语来说，这些没有内容的字段就是“NULL”字段。

　　在数据库表设计的时候，对于这种类型的空字段要特别的留意。一方面，这个NULL字段，不是说其里面存储的是空格。若利用“’’”这个符号去查询空字段的记录的话，往往查不到我们想要的结果。因为在数据库存储的时候，若字段为NULL，则这个值根本没有存储。另一方面，正因为上面这种特性，所以，在表设计的时候，最好把允许NULL的字段放在表的末尾，当数据库比较大或者空字段比较多的话，则可以大大的减少数据库的存储空间。

　　另外，在数据库创建表的时候，是按照列建立的时间来排序的。所以，当某个列建立好之后，除非重新删除再建立，否则无法调整列的顺序。这就要求数据库管理员在创建表之前，就要对列、以及是否为空有一个明确的定义。只有如此，才能够合理安排列的顺序。

　　经验二：养成勤于写注释的习惯。

　　判断一个人是否是数据库专家，从一个“注释”的小习惯中就可以 看得出来。若一个人在数据库开发的时候，勤与写注释，如在建立表或者字段的时候，能够利用comment命令对表与字段进行注释，则可以从一定程度上判断他是这方面的行家。相反，若其开发的数据库，注释没有多少，则基本可以判断，他是一个刚入门的菜鸟。或者说，其没有参加过大型数据库的设计。

　　这主要是因为，在数据库开发过程中，往往不是一个人可以完成的。如在开发一个ERP数据库的时候，可能有些人专门负责开发基础表，而有些人负责维护视图，等等。大家都是分工合作。同时，在前台也有程序员需要调用后台的数据库表与字段。所以，中大型的数据库与应用系统往往是大家协作的结果。

　　为此，为了提高表与字段的可读性，一个数据库管理人员开发的表格，大家都可以看的懂，就需要给表与字段设置比较详尽的注释。在Oracle数据库中，为了给其他伙伴提供有意义的帮助信息，就可以利用Comment命令来描述表、字段的作用以及一些引用的注意事项。这个小小的命令，可以大大提高表与字段的可读性，提高数据库与程序开发团队的协作性。

　　经验三：选择合适的数据类型与长度。

　　虽然数据库系统在处理数据时，某些数据类型是兼容的，或者会对相关的数据类型进行自动的转换。如对于一些日期类型的字段，其也可以赋值给字符类型的字段;整数型的字段跟浮点型的数据类型也是兼容的。但是，数据库设计人员不能因为数据库系统的这个特性，就放宽了对数据类型的把关。因为有时候，如在基础数据导入或者数据成批更新的时候，虽然最后可以成功完成任务。但是，数据库在这个过程中，需要进行数据类型的转换，就额外的增加了数据库的负担。

　　另外，在数据库设计的时候，也需要考虑字段的长度。若在建立表的时候，字段设计的太长，则会浪费存储空间。相反，若设计的太短的话，会影响前台系统的使用。所以，数据库管理员对于字段的长度，也要引起足够的重视。

　　再者，若在创建字段的时候，不能够确认字段长度的话，则最好采用变长的数据类型。如以字符型数据类型为例，就有CHAR与VARHAR2两种。其中，CHAR字符类型主要用来存储固定长度的字符串，允许的最大长度为2000字节。若实际存储的信息内容不到定义的位数的话，则系统会在这些列值为部添加空格，直到其长度到为止。可见，若采用固定长度字段类型的话，即使数据没有这么多，也会占用这么多的存储空间。所以，这种方式下，存储空间的浪费会比较大。后者主要用来存储可变长度的字符数据。当在VARCHAR2列中插入的数据，如果没有到其最大位数的话，则数据库不会在尾部添加空格。从而可以让空间利用最大化。

　　所以，在表设计的时候，数据库管理员要选择合适的数据类型，并且为其设置合适的长度。

　　经验四：确定表需要采用的完整性约束与默认值。

　　有些数据库管理员在数据库设计的时候，喜欢边设计边开发。如在设计表的时候，一开始不确定那些字段要添加约束，哪些字段不能为空，哪些字段需要什么默认值等等。等到需要的时候，再随意添加。这种做事方式，往往会给数据库带来不稳定的隐患。

　　如某个数据库管理人员在建立表的时候，一开始没有给某个字段设置为默认值。后来前台程序开发人员说需要给这个字段添加某个默认值。但是，此时这个表中已经有了跟系统相关的基础数据。有了数据的表格后，往往不允许再重新设置默认值。否则的话，会给数据库造成一定的负面影响。

　　所以，笔者认为，数据库管理员在建立表之前，需要确定表所需要的完整性。如哪些列作为主键;哪些列作为外键;哪些列需要唯一性等等。

　　经验五：确定表需要采用的类型。

　　在Oralce数据库中，存储用户数据可以使用标准表、索引表、筑表和分区表。有时候，基于不用的应用，选择不同类型的数据表，往往可以大大的提高数据库的性能，特别是数据查询的效率。

　　如在合适的情况下，数据库管理员可以使用筑表节省存储空间并提高特定类型的SQL语句的性能。不过，我们平时利用的比较多的出了基本表之外，就是索引表了。因为索引表在某些特殊的应用下，可以表现出很好的性能。如在索引表中，可以通过溢出存储功能提高常用列的查询速度;如果经常需要通过主键来查询整条记录的话，则利用索引表可以明显提高查询效率。当然，索引表也不能够乱用。若索引表所存储的数据，变化比较频繁的话，则采用索引表这种类型的表格，反而会事倍功半。

　　所以，为数据库表选择合适的类型，可以大幅度的提高数据库的性能。当数据库的记录数量越大，这种优势就越明显。

Oracle数据库设计注意的五个问题

一戒：在小型表上不要建立索引。

毋庸置疑，索引可以提高数据库查询的效率。但是，俗话说，过之则不及。索引也必须用在合时的地方。如果索引设置不当，不但不会提升数据库的性能，反而会起到相反的作用。如在小型数据库上设置索引，而且这些表用户更改的比较频繁。如员工基本信息表，就是简单的不超过十个字段。这个表用户需要经常的进行插入与删除操作。当进行这些变更作业的时候，需要对索引进行维护。而这个维护的工作量可能比扫描表空间消耗更多的存储空间。从而不但起步到改善数据库性能的作用，反而是在拖后腿。

所以，在数据库设计的时候，要做到的第一个戒条就是，不要再用户经常更改的小型表上建立索引。否则的话，是得不偿失的。

二戒：不要用用户的键。

如我们在设计一个ERP系统数据库的时候，有一张销售订单表。在这张表中，有一个销售订单号。那么我们能否利用这个单号作为关联其他表的外键呢?如在销售出货单上，需要关联到销售订单。这个时候，我们能否把销售订单单号作为跟出货单关联的关键字呢?

答案是可以的，但是不是最优选择。我们可以看一下ERP的后台数据库。在销售订单表上，除了销售订单号这个唯一表示销售订单纪录的字段外，还有一个字段就是销售订单ID。在前台的出货单界面上虽然显示的是销售订单号码，但是，在后台却存储着的是销售订单ID。也就是说，数据库不是以用户的键作为主键，而是采用了数据库自动维护的单据ID这个字段。

为什么要这么设计呢?这就是笔者今天要谈的第二个戒条，不要用用户的键。通常情况下，不要选择用户可编辑的字段作为外键或者主键。因为这会增加我们额外的工作量。

如果我们把销售订单号作为外键的话，则在创建销售订单纪录后还要对用户编辑字段的行为施加限制，如判断是否违反外键的强制性规则等等。有些系统把销售订单号设置为外键的话，则往往是把这个字段设置为系统自动编号，并且用户不可更改。可是，在实际工作中，企业员工往往需要编辑这个字段。员工需要编辑这些不可编辑的字段时系统缺乏灵活性的缺陷就体现出来了。而且，当用户输入完数据保存的时候再提示纪录不符合要求，则也不是很人性化的设计。

另外，我们还必须为此设计一些检测和纠正键冲突的方法。如考虑这个外键的直是否在其他数据表中存在等等。虽然这通常只需要我们花点时间就可以搞定。但是从数据库性能上来说，这个代价就比较大了。再则，如此的话，就不能够很好的把系统的基本数据跟企业员工的数据实现很好的隔离。

所以，笔者认为，不要用用户的键来作为我们数据库设计的主键或则外键。或者说，数据库设计时用到的键要让数据库系统进行自动维护，用户不得更改这个维护规则。

三戒：不要用商务规则来实现数据的完整性。

数据的完整性有好几种实现方法。如可以通过数据库约束实现数据完整性;也可以通过前台系统的商务规则来实现数据的完整性。不过，笔者这里要建议的是，在一些大型的数据库中，不要试图通过商务规则来实现数据的完整性，而尽可能的通过数据库的约束来实现。因为若通过商务规则来实现完整性，往往会出现一些莫名其妙的错误。

如笔者就遇到过这一个案例。在数据库设计的时候，把某个字符型字段长度限制为最长50位。而在前台应用程序中，却限制了60位。在员工数据数据的时候，在前台应用程序中，可以输入55个字符。但是，下次用户查询的时候，却发现后面几个字符没有了，只剩下前面那些内容。这主要是因为在数据保存的时候，超过了数据库的最长位数限制。数据库就会自动把后面几个字符去掉然后保存。如此，用户在前台输入数据的时候，以为可以保存。但是，实际上数据库中存储的数据是不全的。

所以，笔者的第三个戒条就是，不要利用商务规则在前台实现数据的完整性。只要有可能，就要尽量在数据库系统层面实现数据的完整性。在数据库层面实现数据完整性的同时，需要注意用户的友好性。

一是要把违反约束信息尽可能详细的回馈给用户。如销售订单号，在数据库系统中设置了唯一性约束。则当用户在建立销售订单的时候，销售订单号重复时，就需要把这个约束的详细信息反馈给前台用户。若只显示不能够保存这个错误信息往往是不够的。这会让用户摸不着头脑。

二是在必要的时候，可以利用触发器来实现数据的完整性。虽然在功能设计上，我们不建议在Oracle数据库中采用触发器来实现。如要把某个小写金额转换为大小金额。我们是建议通过前台应用程序实现。因为应用程序的执行效率要比数据库的触发器高。但是，在数据库数据完整性上，在必要的时候，若靠数据库约束无法实现完整性，我们仍然建议采用触发器，而不是前台应用程序来实现。在任何情况下，不要依赖于应用程序来实现数据完整性。否则的话，很难保证数据库约束与商务层约束的一致性。

四戒：在可能的情况下，不要让前台应用程序直接访问数据表。

其实，在数据库基础表与前台应用程序之间，还有一个很好的“中间人”，那就是视图。试图是数据库基础表的一个抽象。他除了可以保障数据的质量外，还可以有效的访问前台应用程序对于数据的非法访问。所以，一些安全性级别比较高的数据库系统，在数据库设计的时候，往往会在数据库和前台应用程序代码之间提供“视图”这个中间人，让其作为基础表的“新闻发言人”。如此，前台应用程序在没有必要的情况下，可以不直接访问数据表，而是通过视图来对表实现间接的访问。

如在进行数据导入程序设计的时候，通过视图来实现则是一个很理想的方法。如用户现在要导入产品信息，包括产品基本信息、供应商信息、价格信息等等。这些信息在数据库中往往包含在三种表中，分别为产品基本信息表、供应商信息表、产品价格信息表。若前台应用程序直接访问基础表的话，就需要分别访问这三张基础表。这不但效率比较低，而且也不容易实现数据的完整性。此时，我们就可以利用视图，把一些必须要填入的字段组合在一张可更新视图中。如此，前台应用程序只需要访问一个数据库对象即可。

再者，在数据库报表设计上，更是要通过视图来实现。而不要通过传递一段SQL代码来查询基础表。这对于数据的安全性会带来比较大的威胁。

所以，第四个戒条就是，在可能的情况下，不要让前台应用程序直接访问数据表。

五戒：不要一直让用户输入数据。

有些字段其实不一定要让用户输入，只需要用户选择即可。如在人事管理系统中，企业员工所属的民族、职位、省份等等就没有必要让用户手工输入。而可以通过列表的形式让员工来进行选择。这种手段，是提高数据完整性的最佳方式之一。若能够给用户提供一个详细的列表供其选择，这样将减少键入代码的错误，同时提高数据库的一致性;也可以提高用户界面的友好性。

所以，在数据库设计的时候，尽量使用列表字段来供用户选择。若连省份等等字段都要用户手工输入的话，则我们在数据库完整性所花费的时间，就要很多。如在数据保存的时候，都要去判断用户输入的数据是否合乎完整性的规则。这显然工作量要比设计一个列表字段多得多。

故数据库设计的第五个戒条就是不要老是让用户手工输入数据。提供列表让用户进行选择，用户不仅可以提高效率，我们也可以省事，同时，也能够保障数据的准确率。

oracle 数据库设计的一些原则

一

1.  先建立逻辑模型，也就是ER图  ，再映射为物理模型。

2. 关于范式， 标准化数据模型一般都不是最终的结果，但他始终是建模最好的起点。

键，完整的键，除了键没有其他东西。

3. 关于数据类型的选择。

由于oracle在数据类型的物理存储上采用非常灵活的方式，因此从存储和性能考虑，使用限制性很强的数据类型或者精度 并没有优势。

二

选择数据类型时，要注意以下方面：

1.大部分情况下，不管你如何限制数据类型，Oracle内部都会使用大范围高精度的浮点方式进行存储，针对于数字和日期。

就算你给一个数字指定了精度，这个精度更多的意义在于约束数据或定义文档，而不是为了优化性能。

也有例外的情况，就是精度能够减少数据的长度，就会有利于性能的提高。

2.固定长度的字符串都会占用一个固定长度的存储空间。 采用固定长度可以降低碎片，但是可能会导致较大的平均行长，导致全表扫描开销加大。

因此，除非你十分确定字符串的长度是确定的，比如MAC地址，否则你就应该选择变长字符串类型。

3 varchar在11g之后全部用varchar2替代，现阶段 2者是一样的。

4. 对于大文件，推荐使用 lob类型。  Blob   二进制， Clob  文本，bfile   外部储存。

三 关于人造建：

人造键通常会比自然键带来更好的性能。

他通常由一个数字类型构成。

相比自然键，会减少表连接的开销和索引查询的开销。

逻辑模型不要一对一映射到物理模型，逻辑主要考虑功能的实现，物理 主要考虑 性能和储存方式，，这样可以大大节约以后调优的时间。！！

四  关于表类型的选择

后谈

五  关于null 值

普通索引不要存null，null不会走索引，只能全表扫。

 组合索引 和位图索引可以储存null。

采用null可以降低行的平均长度，从而一定程度上提高全表扫描的性能。

将查询null 更改为查询一个默认值，就是为了走索引。！！

null值的储存需要一个字节的储存空间。

 

六 列的顺序

访问靠后的列，比靠前的列 需要额外消耗少量的CPU资源。 基于此，把经常访问的列放到前面会带来少量的性能提升。

七 反规范化

1. 复制列值

主要为了避免使用表连接进行查询。

三  物理方面

物理存储方案

1. 当往表中插入新纪录的时候，oracle需要扫描空闲数据块链表。 ASSM 能够自动的很好的完成 空闲数据快链表 以避免 链表争用。针对对插入事务频繁的表。

2. 通过合理设置pctfree 来避免行迁移。数据走，留指针。

3. 在一个事务更改一个块的时候，会获得事务槽，如果事务槽无法自动增加分配，那么事务将会等待。

4，数据压缩，基本都是说的能够提高全表扫描的性能，我的理解是对于范围扫描，也可以提高性能。 字符串的压缩率大于数字类型，对磁盘中数据的压缩收益要大于对内存中数据的压缩。

5 关于lob

一般储存超过4000字节的数据，否则用varchar2来储存。 通常情况下，Lob数据不会跟同一行记录的其他列储存在相同的数据块中，只有lob对象不到4000 ，才inline储存。

控制方式： enable/disable storage in row。

如果LOB字段是经常需要访问的字段，那么建议还是采用inline储存。因为访问外部储存 的lob需要额外的IO。

请设置db_securefile参数， 可以将新的lob列的默认储存方式设置为 secure file。

6 关于分区

分区主要在与2点， 分区消除，便于管理历史分区数据而不影响当前分区。