不管是做表设计，还是维护数据库，而关于字段和表，我还真碰到过很多有意思的。精巧的就留着压箱底了，咱在这仅举一些不良的例子说说.
案例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，都说不清楚， 直到某人一拍脑袋，记起来了， 好像以前有个什么业务逻辑有用到过。
或因为某个临时原因加的，现在已经没有用了。甚至出现某些表都会无人认领的情况。
成这种现象出现的原因。唉.
我暂时记起了这么多，印象中现在这些现象越来越少见到了，这真是好事。 另外，不知你们有没见过更有趣的？ 欢迎补充啊。
