
标准命名规则要满足如下要求:\x0d\x0a以字符开头\x0d\x0a30个字符以内\x0d\x0a只能包含A-Z,a-z,0-9,_,$,#\x0d\x0a不能和同一个用户下的其他对象重名\x0d\x0a不能是oracle服务器的保留字\x0d\x0a\x0d\x0a还有一类是非标准命名,可以使用任何字符,包括中文,oracle中的保留字,空格等等都是可以的,但是需要将对象名用双引号引起来。\x0d\x0a例如: create table “table” (test1 varchar2(10))将会建立一个表名为table的表。并没有什么语法错误。但这这样以后就需要以后在使用这个对象时必须用双引号经对象引起来。\x0d\x0a非标准命名在后续使用中容易因为忽略双引号导致种种错误,如非必要,个人不建议使用。ORACLE
数据库中 表是最基本的内容 可以说 表设计的好坏直接跟数据库的性能相关 所以 在设计表的
时候 除了要遵循其固有的数据库准则之外 还需要看个人的数据库管理经验 下面我就把这些经验分享一下 或许对大家有所帮助 一 表该存放在哪里? 我们都知道 在ORACLE数据库中 使利用空间这个概念来管理表对象的 在数据库创建的时候 数据库中已经建立了一些表空间 那么当我们新建立表的时候 这个新表的位置该放在什么地方呢?这就好像吃饭时的坐的位置一样 是有讲究的 一般来说 我们在新建表的时候 至少要遵循如下建议 一是在数据库创建的时候 在数据库中已经有了一个SYSTEM的表空间 一般情况下 这个表空间中 只包含数据字典及Oracle系统对象 如果我们将我们的表建立在这个空间上
的话 那是要降低数据库的性能的 所以 一般我们是不建议用户把表格建立在这个空间上 但是 若我们不只一个人维护数据库 如有八个人共同设计数据库系统时 如何才能保证其他用户不在SYSTEM表空间中建立数据库表格呢?最好的办法就是通过权限控制 如我们可以给每个数据库设计人员指定一个默认的表空间 让他们只能在这个表空间中建立表格 如此的话 就能防止他们在SYSTEM表空间中建立自己的数据表格 从而对数据库的运行性能产生不良影响 所以 若给每个用户设置默认表空间的话 那么用户在建立具体的表时 不用具体指定表空间了 二是我们在为某个应用设计数据库的时候 最好先对表的空间进行规划 一般情况下 不要把数据表随意的分散到不同的表空间中去 如我们在为一个ERP系统设计数据库的时候 若把采购部门相关的表跟销售部门相关的表放到两个不同的表空间中去 这是不明智的做法 这么处理的话 会降低某些数据库管理和维护 *** 作的效率 如数据的备份与恢复 *** 作而且 也无法集中管理属于某个特定应用的数据 所以 我们一般建议 在规划数据库表空间的时候 把相同应用的表放在同一个表空间中去 如果要区分不同部门或者不同模块的表的话 我们可以在表的命名上动脑子 如我们在设计ERP系统的数据库中 可以根据其应用模块的不同 在前面加上前缀来进行识别 如跟系统基本配置相关的表 我们可以用AD为前缀而跟销售部门相关的表 我们可以加上SA前缀等等 如此的话 这些表具体是属于哪个模块的 就一清二楚了 完全没有必要为此设置不同的表空间 这是ORACLE数据库初学者经常会犯的错误 主要是对ORACLE表空间的定义不是很熟悉所导致的 二 对预计存储数量比较大的表时 要给与额外的重视 有些表非常的大 我们这边说的大 不一定是说结构复杂 而是指在这个表格中 预期会存储比较多的数据 为了提高对这个表格的处理效率 我们在事先要做出一定的安排 否则的话 后续对这些大表进行查询 插入等 *** 作的话 速度会很慢 所以 我们就有必要在数据库设计的时候 先预先估计一下表的数据存储量 把一些数据量大的表格 做一些额外的设置 如在ERP软件的数据库设置中 一般来说 产品数据与物料清单数据这两个表的数据量会比较大而从长远看的话 销售订单 采购订单 生产订单 记账凭证等这种单据类相关的表格其数据量也会比较大 一年两年可能感觉不出来 但是 到十年后 这个纪录数量就会很庞大 而像ERP系统这种大型的信息化管理项目 用个几十年时很正常的事情 而且 为了记录的完整性 也不建议用户把以前的数据删除 所以 为这种应用进行数据库设计的时候 要充分考虑这些大表的性能问题 具体的来说 设计大表的时候 可以考虑遵循如下的建议 一是不要为大表设置存储的限制 在ORACLE数据库中 可以为每张表格设置存储配额限制 如此的话 表最大容量就不能超过这个限制 对于一些数据容量比较小的表格 这么设置时合理的 可以提高空间的利用率 但是 若数据量比较大的话 就不建议事先设置表的存储空间了 如ERP系统的销售订单表 其刚开始可能记录量很小 第一年预计只有 G的记录容量 但是 估计在十年后 这个记录容量就会达到 G了 在这种情况下 我们怎么来给其设置存储空间呢?一开就设置 G空间 这也是不合理的 而且 设置存储空间 就意味着有可能产生存储碎片 从而影响到数据查询的效率 所以 在数据库表的设计过程中 若某些应用的表可能会有比较大的数据容量时 建议不要对其存储空间做出任何的限制 二是要为这大表分配足够的临时空间 如我们使用ERP系统时 要查询产品资料信息 我们都知道 产品信息的话 有些企业这个纪录数非常的庞大 而且在查询时 我们还会经常的进行排序 *** 作 如有时候会按照产品编码对查询出来的数据进行排序 当记录少的话 还好但是 当记录多的话 这个排序动作 要求具有比较大的临时存储空间 所以 当某个表预计会有很大的记录数量的时候 我们就要给其分配足够多的临时空间 临时空间的存储参数设置取决于临时表空间的默认储存参数设置 我们可以更改这些参数 以达到我们对要求 若没有给大表分配足够多的临时空间的话 则排序的动作将会很慢 而且很可能不成功 三是要考虑将表与表的索引分离存放 大表所对应的索引通常也比较大 一般来说 索引的数量是随着表记录的数量增加而增加 两者是接近于一个正比例的关系 所以 通常表的记录容量大的时候 索引数量也会很庞大 针对这种情况 我们考虑突破我们上面讲的表空间的规则定义 而考虑把表和他的索引分别存储于不同的表空间中 甚至在条件允许的情况下 分别存储于不同的硬盘中 这么做的好处是什么呢?最大的好处是让索引比较容易的获得所需要的连续的存储空间 从而提高输入输入的效率 通俗的说 就是可以提高数据的查询效率 如不这么处理的话 查询大容量的记录的话 数据库可能需要花费 秒而如此设计的话 就可能把时间缩短为 秒 这是一个很明显的性能改善 三 如何给表命名? 上面我在讲如何为表分配存储空间的时候 已经讲到过这方面的问题 下面 我就将对这个问题进行详细的描述 以帮助数据库管理员掌握一套好的数据库命名规则 首先 毋庸置疑的 在为标命名的时候 要遵循ORACLE数据库的基本命名规则 如不能以数字开头为表命名 如不能利用数据库的关键字为表命名 如表的名字不能重复等等 这些是最基本的要求 就不用我多费口舌了 除了要遵循这些基本的命名规则外 在实际工作中 为了数据库后续的维护等方面出发 我们还是要遵循一些额外的规则 这些规则跟ORACLE定义的规则不同 我们所讲的规则没有约束力 可以说 只是业界的一些共识而已 你若不怎么处理 ORACLE数据库也不会说你错误 只是后续维护的时候 会比较麻烦而已 一是在对数据库命名的时候 最好能跟体现表的分类关系 如最常见的 我们在设计数据库的时候 表都是按系统的具体模块来区分的 如根据前端系统要求的不同 数据库的表大致可以分为系统基本配置表 销售模块表 采购模块表 报表模块表等等 我们可以根据这些模块的不同 分别给与不同的前缀来区分 这么做的好处是很明显的 如一看到表最大名字 就可以知道这个表是属于哪个应用的 哪个模块的 这无疑可以提高数据库设计与前台软件开发的效率 同时 数据库中默认的排序规则是按名字来排序的 所以 为表格设置类别前缀的话 可以把同一类的表格排在一起 方便我们察看 二是对表格命名的时候 要考虑可读性 而不能随便阿狗阿猫的乱取名字 最常见的是 那些刚学数据库的人 在表命名的时候 如要建几张测试表 就会随便命名如TEST TEST 之类的 虽然这只是测试 但是 也不符合我们的命名过则 要做测试的话 那就以TEST开头 然后后面加上具体要测试的内容 如此的话 我们才可以通过表的名字知道该表具体的用途 而不用打开表去看里面具体的结构或者注释才能知道我们需要的信息 所以 在设计表的名字的时候 还要关注一下其的可读性 lishixinzhi/Article/program/Oracle/201311/18317
在数据库中创建对象时,管理员也要对其进行取名。现在谈谈取名的一些技巧。 一、表名大小写的控制 一般情况下Oracle数据库中的表名或者列名是不区分大小写的。在创建表或者列的时候,即使管理员采用了小写的名字,数据库在将其保存到数据字典之前,会先将其转换为大写,再将他们保存到数据字典中。这也就是为什么我们取名使用小写的子母取名,但是下次查看表的名字的时候,却变成了大写。 虽然说Oracle数据库中表与列等数据库对象对于大小写是不敏感的,但是如果数据库管理员确实有需要要让数据库系统对表的名字区分大小写,这也是可以做到的。通常情况下,如果把名字使用双引号括起来,则在Oracle数据字典中就会成为区分大小写的名字。不过笔者这里要提醒各位数据库管理员,虽然说从技术上可以让数据库系统强制取分大小写,但是在实际工作中,包括在内的绝大部分数据库管理员可能都不建议这么做。因为如果有混合的大小写存在,那么在引用这些表或者列名称的时候就需要特别的小心。因为即使用户或者数据库管理员有着过目不忘的本领,也很难准确的记住这些名称的大小写歌时。如果数据库管理员硬要这么做的话,那么很可能是自寻烦恼。在查询时或者其他作业时,要严格区分大小写那是一件很头疼的事情。为此,对于这个大小写的控制,笔者建议数据库管理员要谨慎使用。除非有充分的理由,否则的话,不要轻易使用这个双引号来控制大小写。 这个双引号不仅可以用来控制大小写,还有一个比较特殊的作用,就是用引用一些特殊的字符。如在建立表格的时候,需要设置一个名牌号的字段。有些数据库管理员习惯使用num#类似的名称。这不会违反数据库的取名规则。不过在处理的时候会比较麻烦。如利用create语句建立表格的时候,需要给这个字段名称加上双引号。否则的话,执行这条语句的时候,数据库会拒绝执行并向用户提示错误信息。类似的特殊符号还包括一个$美元符号。他们在建立表格的时候,在语句中都需要使用双引号。不过字段建立好之后,在引用这些对象的时候,不需要使用双引号了。同理,虽然Oracle数据库支持这些特殊符号,但是笔者不鼓励数据库管理员在表或者列的取名中采取这些特殊的符号。这有可能给后续的引用带来不必要的麻烦。 二、牢记取名空间 在Oracle数据库中,跟其他的数据库不同,有一个叫做取名空间的概念。在同一个取名空间中,其名字不可以重复。如表与视图就共享同一个取名空间,为此就要求不仅表的名字不能够相同,而且表的名字与视图的名字也不能够相同。因为他们处于同一个取名空间。类似的,表与函数也是同处于一个表空间,为此他们也不能够同名。不过表与索引、表与约束等等却属于不同的取名空间。也就是说,表的名字可以与约束的名字相同。所以说,数据库管理员在给表等对象取名的时候,一定要了解哪些对象共享同一个名称空间。如果在同一个名称空间内的,即使对象不同(如视图与表),但是他们仍然不能够取相同的名字。 为了避免同一个取名空间内重名的现象,笔者建立在取名的时候最好能够根据对象的不同加上对象的固有前缀。如大部分的数据库管理员,在给表取名的时候,一般不会表名前面加上表对象的前缀。但是在定义函数或者视图对象的时候,则会加上前缀。如在函数前面可能会加上FN的前缀,而在视图前面可能会加上vi的前缀。如此的话,在同一个取名空间内也不用担心对象重名的问题。不过无论怎么说,这个取名空间的概念数据库管理员必须牢记。即使在实际的工作中,可以通过前缀等手段轻易的避免这个陷阱,但是在Oracle数据库管理员的认证考试中,这个取名空间也是一个必要的知识点。所以无论从实际的工作还是认证考试的需要,对于这个取名空间管理员都必须要有一个清晰的认识。 三、在表、索引、约束、列之间设置密切的联系 在创建表的同时,可以给表中的某些列添加索引、约束等等。如在员工信息表中,会设置员工编号唯一性约束。在创建约束的时候,也需要对约束进行取名。虽然说也约束与表、列不属于同一个取名空间,所以在取名的时候基本上没有限制。但是为了后续使用的方便,笔者对约束的取名还有一个小小的建议。简单的说,就是给一个与表直接有关的其他对象具有该表的名字是一种好的做法。如现在有一张用户表名字叫做ad_user(在表名前面一般不加对象名,但是可以根据应用软件的模块设计加上模块的前缀),这种表中有一个字段叫做叫做vlaue,用来存储员工的编号。在表设计的时候,需要给这个字段加一个索引。那么这个索引的名字就可以取名为IDX_USER_VALUE(也就是索引前缀+表名+字段名的形式)。这么做有什么好处呢?一是可以确保相关对象的名字不会重复。因为表的名字不会重复,所以将表的名字与列的名字一起组成某个对象的名字,那么其重复的几率可以说基本上没有。二是方便管理员阅读、理解、维护等等。一看到索引或者约束对象的名字时,就可以看到这个是索引或者约束是用在哪个表的那个字段上的。而且也可以知道这个约束是唯一性约束还是检查约束索引时主键索引还是外键索引。给数据库管理员一目了然的感觉。这对于后续的维护、升级、调整、引用等等都提供了方便。 虽然说Oracle数据库中表与列等数据库对象对于大小写是不敏感的,但是如果数据库管理员确实有需要要让数据库系统对表的名字区分大小写,这也是可以做到的。通常情况下,如果把名字使用双引号括起来,则在Oracle数据字典中就会成为区分大小写的名字。不过笔者这里要提醒各位数据库管理员,虽然说从技术上可以让数据库系统强制取分大小写,但是在实际工作中,包括在内的绝大部分数据库管理员可能都不建议这么做。因为如果有混合的大小写存在,那么在引用这些表或者列名称的时候就需要特别的小心。因为即使用户或者数据库管理员有着过目不忘的本领,也很难准确的记住这些名称的大小写歌时。如果数据库管理员硬要这么做的话,那么很可能是自寻烦恼。在查询时或者其他作业时,要严格区分大小写那是一件很头疼的事情。为此,对于这个大小写的控制,笔者建议数据库管理员要谨慎使用。除非有充分的理由,否则的话,不要轻易使用这个双引号来控制大小写。
评论列表(0条)