(06)字段趣事多

    不管是做表设计，还是维护数据库，而关于字段和表，我还真碰到过很多有意思的。精巧的就留着压箱底了，咱在这仅举一些不良的例子说说.

 案例1 .  万能字段

      开一个万能字段，把varchar2加得很大，然后把程序构造的字符串记录到这个中。以后有什么变化也不用加字段了，全向里面加。 这种方法我以前听过，听说曾经流行，没想到最近又见到了。一个用 C++开发的项目就用这样弄。 把协议传过来的字符串这样保存，然后select配合like '%xx%'查出结果到MFC界面读取后再一顿狂解析，再展示成listview或报表。这样搞真是无语了。

 案例2.  为了速度，乱开冗余字段

       我见过一个惨痛的案例，某公司的数据库为了防止xxxx查，放在了HK那边，老板又省不得出钱，造成这边访问时速度很慢, 反应很大.开发在想尽办法后，发现物料表的访问量很大，特别是“物料名称”这个字段到处都有用到，而物料表本身数据量也相当大。所以他们认为，在每个用到物料名称的表上，加上物料名称这个字段，就能大大提高速度了。他们也确实这样做。

      很好，当时的效果好像很不错，速度提升很明显。 但运行一段后就发现，数据库完全乱套了，系统上的各个物料，打印出的报表，很多物料都对不上了。 原来因为这个字段用到的地方太多了，而开发的程序改得并不那么好，很多物料名称的中途变更并不能那么完美的在其它模块体现出来。

      只能说，为了提高速度，适当的用一些开冗余字段等方式有时是可行的，但一定要在可控范围内。如果线上系统这样的更改，一定要做好测试工作再上。

 案例3. 字段的命名很奇怪，

        有英文与拼音共存的，有用无意义的字来命名，还有些把名字取得超长，这，写代码时不痛苦吗？

        嗯，还有关于取中文字段名的我前面的文章已经说过了。最后还有一种，使用保留字命名字段的，使用时带来很大的麻烦。

 案例4.  表结构设计不合理，乱开字段。

       有得没得开一堆 a1....a12,b1....b12之类的字段在一个表上。

    像Oracle ERP或QAD之类商业ERP的表结构可能会在一些表上开一些字段做为用户自定义字段，是有道理。

     但有些做表设计时，则不同，他们会在开表时可能依照某一张实际的报表来开，而刚好这张报表是横向显示的，

     他们就照着这样设计，有几个栏位就开几个字段。

案例5. 明知道Varchar2的好处，仍坚持用char的

    varchar2与char的区别，做数据库的应当清楚，但有些旧系统的表结构用得是char,人们在升级时有顾虑不想动，情有可原，但

新增加的表结构也这样弄，为了一致而一致就有点想不明白了。

案例6. 不恰当的用 BLOB 

    这个真是个折磨。 在有些业务上用blob存一些证件像之类是没问题的。但有人把这个功能放大了，好家伙，把什么文档都向上面存。 一方面使数据库急剧澎涨。另一方面blob显示到界面的响应速度并不令人满意。 对于这种blob类型，在使用前一定要搞清楚需求，是否真有必要，如有些为了安全性考量一定要这样做那就没有办法，否可以采取其他方法达到这个效果。

    方法一:  只在字段中保存文件路径，然后将保存文件的目录共享给应用，使其能访问。问题是这种安全性不太高。

    方法二:  采用Oracle的 BFILE 类型，也能达到同样的效果，且没有了使用急剧澎涨的隐患。

    

案例7.字段无人认领。

    这个在上线过一段时间的系统中有时会见到，有些字段里面有一些值，甚至有建索引，但好像又没看到有地方用到。 

 常是DBA问开发，开发问DBA，都说不清楚， 直到某人一拍脑袋，记起来了， 好像以前有个什么业务逻辑有用到过。

或因为某个临时原因加的，现在已经没有用了。甚至出现某些表都会无人认领的情况。

 文档没即时更新，人员变更，业务变更，维护不留意等都是造 成这种现象出现的原因。唉.

我暂时记起了这么多，印象中现在这些现象越来越少见到了，这真是好事。 另外，不知你们有没见过更有趣的？ 欢迎补充啊。

MAIL:xcl_168@aliyun.com
Blog:http://blog.csdn.net/xcl168