郑州网站建设方案服务,公司官网查询,中关村报价大全手机,国内电商推广Oracle-数据库设计规范建议来源于项目资料目的本规范的主要目的是希望规范数据库设计#xff0c;尽量提前避免由于数据库设计不当而产生的麻烦#xff1b;同时好的规范#xff0c;在执行的时候可以培养出好的习惯#xff0c;好的习惯是软件质量的很好的保证。数据库设计是指… Oracle-数据库设计规范建议来源于项目资料目的本规范的主要目的是希望规范数据库设计尽量提前避免由于数据库设计不当而产生的麻烦同时好的规范在执行的时候可以培养出好的习惯好的习惯是软件质量的很好的保证。数据库设计是指对于一个给定的应用环境构造最优的数据库模式建立数据库及其应用系统有效存储数据满足用户信息要求和处理要求。数据对象的命名规范通用规范使用英文要用简单明了的英文单词不要用拼音特别是拼音缩写。主要目的很明确让人容易明白这个对象是做什么用的 一律大写特别是表名有些数据库表的命名乃至其他数据对象的命名是大小写敏感的为了避免不必要的麻烦并且尊重通常的习惯最好一律用大写数据库对象命名规范表的命名 表名的前缀前缀表名T。为表的名称增加一个或者多个前缀前缀名不要太长可以用缩写最好用下划线与后面的单词分开其目的有这样几个 为了不与其他项目或者其他系统、子系统的表重名表示某种从属关系比如表明是属于某个子系统、某个模块或者某个项目等等。表示这种从属关系的一个主要目的是从表名能够大概知道如何去找相关的人员。比如以子系统为前缀的当看到这个表的时候就知道有问题可以去找该子系统的开发和使用人员视图命名相关表名_V(或者根据需要另取名字)程序包命名程序包名_PKG(用英文表达程序包意义)存储过程命名存储过程名_PRO(用英文表达存储过程意义)函数命名函数名称_FUN(用英文表达函数作用)触发器命名触发器名称_TRI(用英文表达触发器作用)索引命名表名字段名IDX(如果存在多字段索引取每字段前三个字符加下划线组合如在 custom, cutting, curtail 上建立联合索引命名为 表名cus_cut_cur_IDX,如果前三个截取字符相同就从字段名称中不同的字符开始取三个字符加下划线组合如在 custid, custom,custname上建立联合索引就命名为表tid_tom_tna_IDX;唯一索引命名表名字段名UNI(如果存在多字段唯一索引取每字段前三个字符加下划线组合如在 custom, cutting, curtail上建立唯一索引命名为 表名_ cus_cut_cur_UNI,如果前三个截取字符相同就从字段名称中不同的字符开始取三个字符加下划线组合如在 custid, custom,custname上建立唯一索引命名表_tid_tom_tna_UNI;主键命名表名字段名PK(如果存在多字段主键取每字段前三个字符加下划线组合如在 custom, cutting, curtail上建立主键命名为 表名cus_cut_cur_PK,如果前三个截取字符相同就从字段名称中不同的字符开始取三个字符加下划线组合如在 custid, custom,custname上建立主键命名表tid_tom_tna_PK;外键命名表名主表名字段名_FKSequence 命名表名列名SEQ(或者根据需要另取名字)Synonym 命名与对应的数据库对象同名JAVA 命名遵守公司相应的JAVA命名规范数据库对象设计原则表的设计主、外键每个表都必须要有主键。主键是每行数据的唯一标识保证主键不可随意更新修改在不知道是否需要主键的时候请加上主键它会为你的程序以及将来查找数据中的错误等等提供一定的帮助一个表的某列与另一表有关联关系的时候如果加得上的话请加上外键约束。外键是很重要的所以要特别强调 适量建外键。为了保证外键的一致性数据库会增加一些开销如果有确凿的并且是对性能影响到无法满足用户需求的证据可以考虑不建外键。否则还是应该建外键 不要以数据操作不方便为理由而不建外键。是的加上外键以后一些数据操作变得有些麻烦但是这正是对数据一致性的保护。正是因为这种保护很有效所以最好不要拒绝它 以缺省的方式建立外键(即用delete restrict方式)以达到保护数据一致性的目的外键在保护数据一致方面非常有效。如果不建外键数据库中容易出现垃圾数据并且无人知晓。当数据量很大的时候查找这些垃圾数据也是相当困难的。而应用程序在设计时往往没有考虑或者也无法照顾到垃圾数据。因此垃圾数据很可能造成应用程序工作不正常并且表现出来的现象会很奇怪让人摸不着头脑。列的设计字段的宽度要在一定时间内足够用但也不要过宽占用过多的存储空间,对于长度不确定的列采用可变长度的数据类型如 varchar类型 字段的类型及宽度在设计以及后面进行开发时往往要与应用的设计、开发人员商讨以得到双方认可的类型及宽度 除非必要否则尽量不加冗余列。所谓冗余列是指能通过其他列计算出来的列或者是与某列表达同一含义的列或者是从其他表复制过来的列等等。冗余列需要应用程序来维护一致性相关列的值改变的时候冗余列也需要随之修改而这一规则未必所有人都知道就有可能因此发生不一致的情况。如果是应用的特殊需要或者是为了优化某些逻辑很复杂的查询等操作可以加冗余列除非必要否则尽量不使用LONG, TEXT, BLOB, CLOB, NCLOB, LONG, LONG RAW这一类的数据类型而是使用其他可以替代的数据类型优先使用varchar2类型替代CHAR类型除非列宽有严格的要求而且得到应用严格支持记录数单表的记录数一般控制在两千万条 (参考值各应用可以根据实际情况进行适量调整) 以内 记录数在两千万和两亿条之间的表一定要采用分区技术并根据应用的使用情况创建合适的分区标准单个分区内的记录数一般控制在两千万条(参考值各应用可以根据实际情况进行适量调整)以内同时表的索引使用对应的分区索引 记录数超过两亿条的表一定要考虑信息生命周期必须考虑历史数据的剥离并在应用设计中完成对历史数据的相应处理功能(历史数据的剥离规则须经业务使用部门的确认)索引的设计索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。但大量的DML操作会增加系统对索引的维护成本对性能会有一定影响对于插入相当频繁的表要慎重建索引索引也会占相当的存储空间所以要根据硬件环境和应用需求在空间和时间上达到最好的平衡点主要原则适当利用索引提高查询速度当数据量比较大了解应用程序的会有哪些查询依据这些查询需求建相应的索引最好亲自试验一下模拟一下生产环境的数据量在此数据量下比较一下建索引前后的查询速度索引对性能会有一定影响对于DML频繁列的索引要定期维护(重建)。但是索引的结构对于索引的更新(比如在插入数据的时候)是有一定优化的所以不要在没有试验以前过分夸大它对性能的影响。最终还是以试验为准 不要建实际用不上的索引与上条相关如果建的索引并不提高任何一应用中的查询速度则要把它删除有些数据库有相关工具可以发现实际未被使用的索引可以利用一下 索引类型的选择要根据数据分布及应用来决定如何建立索引一般的高基数数据列(高基数数据列是指该列有很多不同的值)时 ,建立BTree索引(一般数据库索引的缺省类型)当低基数数据列(该列有大量相同的值)时可以考虑建立位图索引(如果所选数据库支持的话)但位图索引是压缩类型索引所以DML(增、删、改)的代价更高要综合考虑 索引列的选择如果检索条件有可能包含多列创建联合主键或者联合索引把最常用于检索条件的列放在最前端其他的列排在后面不要索引使用频繁的小型表假如这些小表有频繁的DML就更不要建立索引维护索引的代价远远高于扫描表的代价主键索引在建立的时候一定要明确的指定名称不能让系统默认建立主键索引(可能有些数据库无法指定主键名则例外) 外键必须需建索引。当有一定数据量并且经常以外键所在列为关联进行关联查询时需要建索引(可能有些数据库自动为外键建索引则例外) 当有联合主键或者联合索引时注意不要建重复的索引。举例说明更复杂的情况比如表EMPLOYEES有一个索引建立在列CORPID, DEPARTID, EMPLOYEEID三列上在创建语句中也依据上述顺序就没有必要再为CORPID建立索引也没有必要再建立以CORPID在前DEPARTID在后的联合索引如果EMPLOYEEID需要索引那么为EMPLOYEEID建立一个索引是不与上面的索引重复的DEPARTID列也类似表EMPLOYEES它的主键是建立在列DEPARTID和EMPLOYEEID上的联合主键并且创建主键的语句中DEPARTID在前EMPLOYEEID在后。在这样一 个表里通常就没有必要再为DEPARTID建一个索引了联合索引的情况也一样控制一个表的索引数量尽量使得一个表的索引数量小于五个视图的设计在不太清楚视图用法的情况下尽量不建。因为一旦建了就有被滥用的危险 如果需要建视图只要是打算长期使用的请写入数据库设计中。明确它的用途、目的 建立视图时要明确写出所有要选择出的列名而不要以SELECT *来代替可以使结构清晰可读性增强也不会增加它对表的所有字段的依赖而表是很可能修改的特别是增加字段。就很有可能导致使用该视图的应用程序出错存储过程、函数、触发器的设计触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器一定要经过测试再应用在生产系统中而且必须集中对它文档化。 请把程序包、存储过程、函数、触发器与应用程序一同加入CVS中进行版本控制。因为此四者包含了代码应用程序对他们的依赖程度比对表、视图的依赖程度更高适量但尽量少使用存储过程、函数、触发器。使用存储过程、函数、触发器的影响(1) 可以减少数据库与客户端的交互提高性能(2) 有的数据库还对他们进行了某种程度的编译在执行的时候不用再对其中的SQL等语句进行解析从而提高速度(3) 如果有多个应用使用了不同的开发语言当有某些关键的或者复杂逻辑希望共享则可以考虑使用存储过程或者函数。因为存储过程等在数据库一级是共享的(4) 增强了应用对数据库的依赖如果打算将来移植数据库的话使用得越多则移植的困难越大数据库中的业务逻辑越多(存储过程等)应用以及存储过程等的维护难度也会增大(5) 通常存储过程等没有面向对象的特性不容易设计出易于扩展的结构。当存储过程比较复杂时或者它们相互间的调用关系比较复杂时可能难于维护SQL的设计和使用Sql 书写规范尽量不要写复杂的SQL过于复杂的SQL可以用存储过程或函数来代替效率更高甚至如果能保证不造成瓶颈的话把条SQL拆成多条也是可以的。这与一般的编码规范很相似的首先是要易懂。易懂也就意味着容易维护对较为复杂的sql语句加上注释说明算法、功能注释风格注释单独成行、放在语句前面。 应对不易理解的分支条件表达式加注释 对重要的计算应说明其功能 过长的函数实现应将其语句按实现的功能分段加以概括性说明 每条复杂SQL语句均应有注释说明(表名、字段名 主要是说明此句SQL执行 的作用及所取得结果集的意义) 常量及变量注释时应注释被保存值的含义(必须)合法取值的范围(可选__) 可采用单行/多行注释。(-- 或 /* */ 方式不同数据库可能语法不同) 连接符or、in、and、以及、、等前后加上一个空格 不要用SELECT *SELECT语句中写出必要的要选择的全部列名增强语句可读性避免不必要的选择SELECT * 增加了对所有字段的依赖当表增加了字段后有可能发生错误此外还可能增加了数据的流量查询了一些实际不需要的字段 避免长事务(Transaction)长事务容易造成死锁应该避免单个事务使用的数据库和系统资源不宜超过总资源1-2%(参考值各应用可以根据实际情况进行适量调整,这种情况不适用于数据仓库) 行最长不能超过80字符,同一语句不同字句之间逗号以后空格,其他分割符前空格 where子句书写时每个条件占一行语句令起一行时以保留字或者连接符开始连接符右对齐 多表连接时使用表的别名来引用列 SQL中对视图的引用在不太清楚视图用法的情况下尽量不用。只是因为视图中有自己想要的字段就拿来用是相当普遍和错误的用法。原因如下增加了应用程序对视图的依赖不必要的依赖是越少越好的。当有应用程序依赖了某个视图不久可能其他人因为某种原因会修改此视图原来的应用有可能会受到不同程度的影响 增加了不必要的数据流量对你的实际需求那很可能是一个非常复杂的视图有大量你不需要的字段并且关联了很多你实际不需要的表对数据库资源 会有过多的消耗不要在SQL语句中使用基于rule规则的hint因为在Oracle 10g及以后版本不再支持SQL 性能优化建议系统可能选择基于规则的优化器所以将结果集返回数据量小的表作为驱动表即将结果集返回数据量小的表放在FROM后边最后一个表 大量的排序操作影响系统性能所以尽量减少order by和group by排序操作 如必须使用排序操作排序尽量建立在有索引的列上索引的使用尽量避免对索引列进行计算。如对索引列计算较多请提请数据库管理员建立函数索引 尽量注意比较值与索引列数据类型的一致性(number与number比较、char与char比较)避免使用数据库的类型自动转换功能如SELECT * FROM categoryWHERE id ‘123’; -- id’s type is number对于复合索引SQL语句必须使用主索引列索引字段中尽量避免使用NULL值 对于索引的比较尽量避免使用NOT(!) 查询列和排序列与索引列次序保持一致 尽量避免相同语句由于书写格式的不同而导致多次语法分析(减少数据库的硬分析)如可使用TOAD的格式化工具对SQL语句进行格式化处理; 查询的WHERE过滤原则应使过滤记录数最多的条件放在最前面 在WHERE中数据库函数、计算表达式等等要尽可能将放在等号右边。否则会使所比较的字段上的索引失效如 TO_DATE(‘2001-9-01’,’yyyy-mm-dd’)AND gmt_modified TO_DATE(‘2001-9-02’,’yyyy-mm-dd’);SELECT FROM service_promotionWHERE TO_CHAR(gmt_modified,’yyyy-mm-dd’) ‘20001-09-01’; 而应使用SELECT *FROM service_promotionWHERE gmt_modified in、or子句常会使索引失效尽可能不使用in、or尽量避免在循环中使用SQL语句在循环中尽量使用动态SQL语句提高执行性能 其他与性能有关的设计原则前面与提高数据库访问的性能相关的内容这里就不再重复了下面提出一些与数据库性能极为相关但上文又未涉及的条目大数据量的开发环境开发过程中开发人员往往使用一个非常简单的、只有很少数据的数据库环境便于程序的调试。但是最好还提供一个数据量与真实环境相当的环境数据量和应用的设计目标差不多供开发人员使用。这样开发人员能立刻发现那些非常慢的数据库操作比如写了一个非常不合理的SQL因而能够在此时就排除而不必等到测试或者甚至上线时才发觉。因为很多开发人员由于对数据库的认识不够通常只以完成功能为首要目的容易写出效率非常低的SQL限制使用这里说的限制使用是指如果能有其他的技术途径就不要使用如下的Oracle技术包括DBLink Trigger用Java编写的存储过程等内容模拟测试这里说的测试主要是指模拟实际应用对数据库的操作进行测试并发及访问量要模拟应用的设计需求。主要目的是了解在系统上线后数据库的大概状况避免一上线就崩溃或者慢得不能忍受的情况。提前发现瓶颈做相应的优化应用测试每个应用的测试阶段特别是性能方面的测试也要关注数据库的表现。如果出现瓶颈则根据具体情况根据需要必须修改部分数据库设计并修改相应程序数据库相关工具为需要写SQL的开发人员提供方便的、图形化的客户端软件可以用来执行SQL看到表结构、索引等等如TOAD, PL/SQL Develop软件。
