经理的做法是错误的
表的主要作用是存储数据,主要的设计目标是存取效率查询数据主要使用视图,这样SQL优化和维护比较方便

解决方案 »

  1.   

    to batt()
    其实你说的恰恰也是他们所说的:以后要是改在‘中 共 党 员’的话,那样没改之前的还是‘党员’,可能这也是他们所希望的;但我是这么说的:要是想要保留原来的内容,完全可以在数据字典里再加一条记录如:03--中 共 党 员,然后出用户选择‘中 共 党 员’,但某些人说太麻烦,还不如直接在字段里存放内容而不是代码!
      

  2.   

    to nebulaly
    最终用户根本不知道也没有必要知道数据库里面的存储形式,他只关心数据在界面上的表现形式,这一点肯定是能让其满意的。
      

  3.   

    to rolandzhang()
    对于你的问题是这样回答的:基于目前的存储技术,每记录多增加几十个字节,百万条记录也就几十M,应该不是什么大问题,至于查询效率有没有显著提高或降低,在建了索引的情况下差别不大。我想不出什么好的理由,如果光拿范式是说服不了经理的,现在系统中我做的模块全是存的代码(当初做时自已改成存代码),而别人做的一个模块存的是内容,因为如果今天不能说服我们经理有话,就要连表结构和程序都要改,郁闷!!!
      

  4.   

    每记录多增加几十个字节,百万条记录也就几十M,应该不是什么大问题
    首先,数据库不是这样分配物理存储的,并且update人员身份字段会改变记录长度,增加了行移植的几率至于查询效率有没有显著提高或降低,在建了索引的情况下差别不大
    如果表里面只有一个人员身份字段,确实是这样;但是楼主的表里面有6、7个,难道要对这个表建6、7个索引吗?如果没有索引,只有“人员身份字段”的查询就会引起全表扫描,这种情况下,记录长度对查询效率必然是有影响的当然这些问题并不是容易表现出来的,主要问题是楼上有人说过的,如果数据字典值改变了怎么办?当然,同时对人员身份字段也作更新也可以,只要能够承受这种开销就没有问题关键是,这种开销最后会在用户那里反映出来;)
      

  5.   

    用视图的另一个好处是简化应用程序中的SQL
    这样在不重新编译应用程序的条件下
    还有在数据库端对查询和增删改进行优化,甚至改变增删改行为的机会