数据冗余 关系型?数据冗余的问题?浅谈设计技巧（实例一定的数据冗余）(3)

你拿着这3个表给老板检查，老板希望能够再添加一个商品图片的字段，不过只有一部分商品有图片。OK，你在商品信息表(Wares_info)中增加了一个haspic的BOOL型字段，然后再建了一个新表——商品图片表(Wares_pic)：

商品图片表(Wares_pic)
名称 类型约束条件 说明
pic_id int 无重复 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
pic_address char(200) 不允许为空 图片存放路径

程序开发完成后，完全满足老板目前的要求，于是正式启用。一段时间后，老板打算在这套平台上推出新的商品销售，其中，某类商品全部都需添加“长 度”的属性。第一轮折腾来了……当然，你按照添加商品图片表的老方法，在商品信息表(Wares_info)中增加了一个haslength的BOOL型 字段，又建了一个新表——商品长度表(Wares_length)：

商品长度表(Wares_length)
名称 类型约束条件 说明
length_id int 无重复 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
length char(20) 不允许为空 商品长度说明

刚刚改完没多久，老板又打算上一批新的商品，这次某类商品全部需要添加“宽度”的属性。你咬了咬牙，又照方抓药，添加了商品宽度表 (Wares_width)。又过了一段时间，老板新上的商品中有一些需要添加“高度”的属性，你是不是开始觉得你所设计的按照这种方式增长下去， 很快就能变成一个迷宫呢？那么，有没有什么办法遏制这种不可预见性，但却类似重复的膨胀呢？我在阅读《敏捷软件开发：原则、模式与实践》中发现作者 举过类似的例子：7.3“Copy”程序。其中，我非常赞同敏捷软件开发这个观点：在最初几乎不进行预先设计，但是一旦需求发生变化，此时作为一名追求 卓越的程序员，应该从头审查整个架构设计，在此次修改中设计出能够满足日后类似修改的系统架构。下面是我在需要添加“长度”的属性时所提供的修改方案：

去掉商品信息表(Wares_info)中的haspic字段，添加商品额外属性表(Wares_ex_property)和商品额外信息表(Wares_ex_info)2个表来完成添加新属性的功能。

商品额外属性表(Wares_ex_property)
名称 类型约束条件 说明
ex_pid int 无重复 商品额外属性标识，主键
p_name char(20) 不允许为空 额外属性名称

商品额外信息表(Wares_ex_info)
名称 类型约束条件 说明
ex_iid int 无重复 商品额外信息标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
property_id int 不允许为空 商品额外属性标识，和Wares_ex_property.ex_pid关联
property_value char(200) 不允许为空 商品额外属性值

在商品额外属性表(Wares_ex_property)中添加2条记录：
ex_pid p_name
1 商品图片
2 商品长度

再在整个电子商务平台的后台管理功能中追加一项商品额外属性管理的功能，以后添加新的商品时出现新的属性，只需利用该功能往商品额外属性表 (Wares_ex_property)中添加一条记录即可。不要害怕变化，被第一颗击中并不是坏事，坏的是被相同轨道飞来的第二颗、第三颗击 中。第一颗来得越早，所受的伤越重，之后的抵抗力也越强8)

三、多用户及其权限管理的设计
开发管理类的软件，不可能不考虑多用户和用户权限设置的问题。尽管目前市面上的大、中型的后台系统软件都提供了多用户，以及细至某个内某张表的权限设置的功能，我个人建议：一套成熟的管理软件，还是应该自行设计用户管理这块功能，原因有二：
1.那些大、中型后台系统软件所提供的多用户及其权限设置都是针对的共有属性，并不一定能完全满足某些特例的需求；
2.不要过多的依赖后台系统软件的某些特殊功能，多种大、中型后台系统软件之间并不完全兼容。否则一旦日后需要转换平台或后台系统软件版本升级，之前的架构设计很可能无法重用。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-17340-3.html