其实在数据库中创建对象时，管理员也要对其进行命名。一些有经验的数据库管理员，对其命名也会小心翼翼。既要能够叫的响亮，又要能够代表具体的应用场景。有时候对表等数据库对象进行命名的时候，可能比维护数据库还要伤脑筋。笔者对此就有非常深的感受。在数据库设计的时候，一套命名规则编制下来，脑袋就会觉得很累。不过等大家多编制几套后，就会掌握其中的规律。熟能生巧，掌握了规律再去取名的话，就会简单许多。有时候甚至可以信手拿来。笔者这次就跟大家分享一下对数据库对象进行命名的一些规律。简单起见，笔者以数据库对象表为例，谈谈命名的一些技巧。

　　一、牢记命名空间。

　　在Oracle数据库中，跟其他的数据库不同，有一个叫做命名空间的概念。在同一个命名空间中，其名字不可以重复。如表与视图就共享同一个命名空间，为此就要求不仅表的名字不能够相同，而且表的名字与视图的名字也不能够相同。因为他们处于同一个命名空间。类似的，表与函数也是同处于一个表空间，为此他们也不能够同名。不过表与索引、表与约束等等却属于不同的命名空间。也就是说，表的名字可以与约束的名字相同。所以说，数据库管理员在给表等对象命名的时候，一定要了解哪些对象共享同一个名称空间。如果在同一个名称空间内的，即使对象不同(如视图与表)，但是他们仍然不能够取相同的名字。

　　为了避免同一个命名空间内重名的现象，笔者建立在命名的时候最好能够根据对象的不同加上对象的固有前缀。如大部分的数据库管理员，在给表取名的时候，一般不会表名前面加上表对象的前缀。但是在定义函数或者视图对象的时候，则会加上前缀。如在函数前面可能会加上FN的前缀，而在视图前面可能会加上vi的前缀。如此的话，在同一个命名空间内也不用担心对象重名的问题。不过无论怎么说，这个命名空间的概念数据库管理员必须牢记。即使在实际的工作中，可以通过前缀等手段轻易的避免这个陷阱，但是在Oracle数据库管理员的认证考试中，这个命名空间也是一个必要的知识点。所以无论从实际的工作还是认证考试的需要，对于这个命名空间管理员都必须要有一个清晰的认识。

　　二、表名大小写的控制。

　　一般情况下Oracle数据库中的表名或者列名是不区分大小写的。在创建表或者列的时候，即使管理员采用了小写的名字，数据库在将其保存到数据字典之前，会先将其转换为大写，再将他们保存到数据字典中。这也就是为什么我们命名使用小写的子母命名，但是下次查看表的名字的时候，却变成了大写

虽然说Oracle数据库中表与列等数据库对象对于大小写是不敏感的，但是如果数据库管理员确实有需要要让数据库系统对表的名字区分大小写，这也是可以做到的。通常情况下，如果把名字使用双引号括起来，则在Oracle数据字典中就会成为区分大小写的名字。不过笔者这里要提醒各位数据库管理员，虽然说从技术上可以让数据库系统强制取分大小写，但是在实际工作中，包括在内的绝大部分数据库管理员可能都不建议这么做。因为如果有混合的大小写存在，那么在引用这些表或者列名称的时候就需要特别的小心。因为即使用户或者数据库管理员有着过目不忘的本领，也很难准确的记住这些名称的大小写歌时。如果数据库管理员硬要这么做的话，那么很可能是自寻烦恼。在查询时或者其他作业时，要严格区分大小写那是一件很头疼的事情。为此，对于这个大小写的控制，笔者建议数据库管理员要谨慎使用。除非有充分的理由，否则的话，不要轻易使用这个双引号来控制大小写。

　　这个双引号不仅可以用来控制大小写，还有一个比较特殊的作用，就是用引用一些特殊的字符。如在建立表格的时候，需要设置一个名牌号的字段。有些数据库管理员习惯使用num#类似的名称。这不会违反数据库的命名规则。不过在处理的时候会比较麻烦。如利用create语句建立表格的时候，需要给这个字段名称加上双引号。否则的话，执行这条语句的时候，数据库会拒绝执行并向用户提示错误信息。类似的特殊符号还包括一个$美元符号。他们在建立表格的时候，在语句中都需要使用双引号。不过字段建立好之后，在引用这些对象的时候，不需要使用双引号了。同理，虽然Oracle数据库支持这些特殊符号，但是笔者不鼓励数据库管理员在表或者列的命名中采取这些特殊的符号。这有可能给后续的引用带来不必要的麻烦。

　　三、在表、索引、约束、列之间设置密切的联系。

　　在创建表的同时，可以给表中的某些列添加索引、约束等等。如在员工信息表中，会设置员工编号唯一性约束。在创建约束的时候，也需要对约束进行命名。虽然说也约束与表、列不属于同一个命名空间，所以在取名的时候基本上没有限制。但是为了后续使用的方便，笔者对约束的命名还有一个小小的建议。简单的说，就是给一个与表直接有关的其他对象具有该表的名字是一种好的做法。如现在有一张用户表名字叫做ad_user(在表名前面一般不加对象名，但是可以根据应用软件的模块设计加上模块的前缀)，这种表中有一个字段叫做叫做vlaue，用来存储员工的编号。在表设计的时候，需要给这个字段加一个索引。那么这个索引的名字就可以取名为IDX_USER_VALUE(也就是索引前缀+表名+字段名的形式)。这么做有什么好处呢?一是可以确保相关对象的名字不会重复。因为表的名字不会重复，所以将表的名字与列的名字一起组成某个对象的名字，那么其重复的几率可以说基本上没有。二是方便管理员阅读、理解、维护等等。一看到索引或者约束对象的名字时，就可以看到这个是索引或者约束是用在哪个表的那个字段上的。而且也可以知道这个约束是唯一性约束还是检查约束;索引时主键索引还是外键索引。给数据库管理员一目了然的感觉。这对于后续的维护、升级、调整、引用等等都提供了方便

四、让表名与列名反应该表与列的含义。

　　有些数据库在设计的时候，给表与列取名的时候采用的是阿拉伯的随机数字。如1111、1112等等。这虽然便于扩展，但是笔者并不赞同这种命名方法。因为此时数据库管理员在工作的时候，旁边还不得不有一份对象名与实际内容对应的一份表格。这操作起来非常的麻烦。有些管理员也许会说，可以通过同义词功能来为这些表取具有一定含义的别名呀。这对于数据库规模比较小的应用，如总共只有几十张表格，或许是可行的。但是如果有成千上百张表格，这个定义同义词的作业就比较累人了。所必这认为这是的得不偿失的。在给表或者列命名的时候，最好能够反映该表与列的含义。

　　另外有时候对表进行命名的时候，还需要考虑应用软件的设计。因为程序开发人员需要引用数据库中的对象。所以在命名时也需要考虑到他们的便利。笔者建议如果应用软件考虑到模块化设计的时候，如将一个应用软件分为销售、生产、采购、仓库、财务等模块时，那么各个模块在数据库中对应的表最好加上相关的前缀。如此的话，无论是数据库管理员还是程序开发人员，在使用这些表的时候，都可以通过前缀来缩小其选择的范围。从而提高其工作的效率。只要在应用程序设计时规划好模块，然后为每一个模块取一个简单易懂的前缀(最好具有相同的字符数)，就可以了。这一点小小的改进，就可以为后续使用这些数据库对象提供很大的方便。为此笔者强烈建议让表名反应表的用途，反应应用软件的设计思路