comment on的重要意义

在db2和oracle的使用中经常会用到comment，但是今天突然发现自己还不理解到底为什么要使用comment，平时没有感觉出来使用comment有什么实际的作用啊？

于是搜索了一下，发现这篇文章写得不错，为我解惑了，虽然写的是关于oracle的，但是在db2中也是一样的。先收藏了。

 

原文地址：

http://blog.csdn.net/liguihan88/article/details/3002403

无疑注释现在都被大家接受和认可，在大家编程用的IDE中都提供或有第三方插件来支持提取注释内容实现
快速了解结构的功能。但在数据库的脚本编写方面我也是经历了百般折磨后总结了一些东西发来与大家切磋。
下面来看一个Oracle建表的方式。
create table ctable_name
(
       field1 varchar2(20), --注释的内容1
       field2 number,       --注释的内容2
       field3 char(2),      --注释的内容3
       field4 date          /*注释的内容4*/
)
之前一直都是这样来建表，觉得快速也好理解，其实数据库结构不复杂的情况下我也喜欢这种方式，但当数据库结构很复杂的时候维护起来就很头疼，一个SQL几百K，看的你眼都花了，而且有N个这样的SQL文件，那么在对不了解的复杂的数据库结构实现快速编程方面，为了了解结构查找注释的工作量也很大。
尤其公司项目已经做了5年了，好多SQL脚本都没了，那么数据结构只能问老的同事，但对于人员更替频繁的公司当老程同事都换了几批，都不在了，没人可问，那么维护人员或后续开发人员就掉进了无尽的痛苦中，好多问题都是出在这上面。后期投入成本也是很巨大的。如果数据库结构命名什么的比较规范还好，可以凭字面意思确定大概用途，反之真实苦不堪言。而且知识的传递当中是有人为因素导致的缺失的。举例来说就是一般员工离开公司之前会用一个月的时间来交接，但大部分都是用
一周左右的时间来交接工作，那么交接的自然会有意识的忽略一些小的或掩盖一些有问题的地方只说主要好使的地方，如果交接的是一个对结构了解的同事还好，根据相应的经验，承接不是问题，但如果交接给新的同事，新同事接起来很费劲，而要走的同事要进的公司还催他速度办离职，那么缺失的部分就要新同事来弥补，当然如果他是个负责的人当他发现虽然项目可以进行或说程序可以跑起来但有些东西，一般是细节的东西他还不了解需要打电话给原来的同事来弄清楚，那么也不会有什么问题，但我说的是如果，一般的人在看到项目能够进行（程序能跑起来）是不会去弄那些东西的，这样循环下去，最后维护这个程序或后续开发的倒霉蛋就有的苦吃了，我体会过这样的痛苦，所以我深有体会，估计别的公司一定也会有这种现象。
 
那么总结下可能出现的情况：
1.SQL脚本内容很多，格式不规范，阅读不方便，连带查找也不是很高效。
2.SQL脚本很多，且每个都存在1的问题，仍然不效率。
3.数据库工作交接中存在的细节遗失。
4.出现3的问题而且数据库对象命名不规范，后续维护人员对数据库对象含义存在歧义性，连带产生的问题趋近与无穷大，
精神折磨趋近与无穷大，导致不想干下去跳槽走人的概率趋近于1。
那么总结后当然要提出一个我认为好的解决方案，用comment关键字来解决这个问题，看看下面的方式
create table ctable_name
(
 
       field1 varchar2(20), --注释的内容1
       field2 number,       --注释的内容2
       field3 char(2),      --注释的内容3
       field4 date          /*注释的内容4*/
)
--select * from ctable_name;
comment on table ctable_name is '对表注释的内容';/*给表添加注释的方式*/
select * from user_tab_comments where table_name = 'CTABLE_NAME';/*查询某表的注释*/
 
comment on column ctable_name.field1 is '对field1列注释的内容';/*给列添加注释内容的方式，有多少个列应该写多少个*/
select * from user_col_comments where table_name = 'CTABLE_NAME' and column_name = 'FIELD1';/*查询某表下某列的注释*/
 
上面解决方案把我上面提到的问题都解决了，本质是利用ORACLE中的数据字典的功能，那么虽然在编写脚本的时候可能会多一些工作量，但他能达到的效果远大于那一点工作量。
 
这里的编辑器真烂，截图就不传了，到时候你在数据库里执行上面的语句自己看吧。下面说说他的好处。
1.可以通过SQL语句快速查询，只要知道表名和字段名定位注释极方便快速。
2.注释内容是存储在字典表里的，只要表结构还在，那么SQL脚本即使没有了也可以定位查询。
3.不需要猜字段是什么意思，因为在简表的时候已经给了没有二意的注释，后期承接明确。
4.可以编写自己的小工具来加速数据结构的学习过程，方便新员工。
5.极力推荐大家这么做，同事也可以现在对原库表结构填补注释。
 
匆匆写了一点，很多地方没说的清楚，欢迎的大家来一起切磋。我已经在我后续的项目中这么做了，确实好处颇多，最后套用赵本山的话来结束“谁用谁知道”。