程序设计与数据库结构的粒度

 

      先从我做的一个项目开始这个话题，我单位做的一卡通系统在原来设计的的数据库结构上不断的升级目前好像有点吃不消了。原来我给每个用户分配的用户类型来管理用户的单价。
用户类型 编号 4 数字(3) - √ - 名称 20 文本(202) - × -

水电表类型价格表　 编号 4 数字(3) - √ - 类型 4 数字(3) 1 √ - 子表号 4 数字(3) 1 × - 单价 8 货币(6) 0 √ - 排污 4 数字(3) 1 √ -

用户类型明细　 编号 4 数字(3) - √ 名称 20 文本(202) - √ 子表号 4 数字(3) - √ 单价 8 货币(6) - √ 排污 4 数字(3) - √

        以前都是固定的字表号对应电表或水表，随着系统的升级已经没有字表对应的明确关系了，问题就来了！最初数据库内没有保存“单位”字段，现在又增加了纯净水表计量单位是升（普通水表的计量单位是吨）程序界面上更改表示单位的标签的名称很多，造成了升级可能一个小的标签文字描述的错误，给客户使用上带来概念上的混淆。

        如果最初在设计数据库结构的时候就有单价字段，就避免了这个问题的发生。管理用户单价的类型的名称和 单价值 单位关联每个单价都对应一个单位描述就避免了上面的问题出现。

           总结以上就是要合理的来设计数据库的粒度，每个数据表尽可能完整的描述清楚数据表的成员，但粒度也不可以太细没有意义的成员在以后的维护中一样会带来麻烦，就是还要考虑这些成员是怎么来的为什么要用。

                                      
                                   段利庆    QQ：664340775