- 浏览: 958618 次
- 性别:
- 来自: 魔都
文章分类
- 全部博客 (745)
- MultiThread (19)
- My Plan (118)
- JavaBasic (61)
- MyInterview (104)
- InternetTechnique (5)
- ProjectConclusion (1)
- Maven (5)
- MogoDb (5)
- Hadoop (11)
- Memcached (6)
- TechniqueCollect (1)
- Ibaits (1)
- Android (34)
- ItLife (40)
- Tree (2)
- ProjectArchitect (7)
- Open Source (3)
- liunx (5)
- socket (8)
- Spring (27)
- DesginPattern (35)
- WebBasic (13)
- English (13)
- structs (1)
- structs2 (2)
- Oracle (17)
- Hibernate (2)
- JavaScript (4)
- Jdbc (1)
- Jvm (15)
- Ibatis (1)
- DataStructures (13)
- Https/Socket/Tcp/Ip (3)
- Linux (4)
- Webservice (7)
- Io (2)
- Svn (1)
- Css (1)
- Ajax (1)
- ExtJs (1)
- UML (2)
- DataBase (6)
- BankTechnique (3)
- SpringMvc (3)
- Nio (3)
- Load Balancing/Cluster (3)
- Tools (1)
- javaPerformanceOptimization (8)
- Lucene(SEO) (1)
- My Think (80)
- NodeJs (1)
- Quartz (1)
- Distributed-java (1)
- MySql (7)
- Project (4)
- junit (4)
- framework (1)
- enCache (1)
- git (2)
- SCJP (1)
- sd (1)
最新评论
-
lkjxshi:
你都这水平了还考这个证干嘛
SCJP 认证考试指南 -
钟逸华:
问的真多
百度java开发面试题(转) -
zuimeitulip:
觉得我就是这样的,从小阅读量就很少,导致现在的读的速度非常慢, ...
让读书成为一种习惯 -
DDT_123456:
我觉得你是不符合要求。问你hashmap的那个问题,你那样回答 ...
阿里面试2(转) -
jingjing0907:
刚刚写了很多读过此博客的感受,竟然没有发上去,以为我注册账号还 ...
让读书成为一种习惯
(转)浅谈数据库设计技巧(上)
浅谈数据库设计技巧(上)
http://www.knowsky.com/4937.html
说到数据库,我认为不能不先谈数据结构。1996年,在我初入大学学习计算机编程时,当时的老师就告诉我们说:计算机程序=数据结构+算法。尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主,但我还是深深赞同8年前老师的告诉我们的公式:计算机程序=数据结构+算法。面向对象的程序开发,要做的第一件事就是,先分析整个程序中需处理的数据,从中提取出抽象模板,以这个抽象模板设计类,再在其中逐步添加处理其数据的函数(即算法),最后,再给类中的数据成员和函数划分访问权限,从而实现封装。
数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的,由此可见,数据库并不一定是存储在电脑里的数据^_^),里面记录的是该奶牛场的收支账目,程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据结构所采集到的数据量大到一定程度后,出于程序执行效率的考虑,程序员将其中的检索、更新维护等功能分离出来,做成单独调用的模块,这个模块后来就慢慢发展、演变成现在我们所接触到的数据库管理系统(DBMS)——程序开发中的一个重要分支。
下面进入正题,首先按我个人所接触过的程序给数据库设计人员的功底分一下类:
1、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具,他们往往习惯只设计有限的几个表,实现某类功能的数据全部塞在一个表中,各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西,当程序功能有限,数据量不多的时候,其程序运行起来没有什么问题,但是如果用其管理比较重要的数据,风险性非常大。
2、系统学习过数据结构,但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久,他们在设计数据库表结构时,严格按照教科书上的规定,死扣E-R图和3NF(别灰心,所有的数据库设计高手都是从这一步开始的)。他们的作品,对于一般的access型轻量级的管理软件,已经够用。但是一旦该系统需要添加新功能,原有的数据库表差不多得进行大换血。
3、第二类程序员,在经历过数次程序效率的提升,以及功能升级的折腾后,终于升级成为数据库设计的老鸟,第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率,而且其设计的数据库可拓展性较好,当用户需要添加新功能时,原有数据库表只需做少量修改即可。
4、在经历过上十个类似数据库管理软件的重复设计后,第三类程序员中坚持下来没有转行,而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟,从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见,能够预测到未来功能升级所需要的数据,从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。
5、第三类程序员或第四类程序员,在对现有的各家数据库管理系统的原理和开发都有一定的钻研后,要么在其基础上进行二次开发,要么自行开发一套有自主版权的通用数据库管理系统。
我个人正处于第三类的末期,所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时,由于我很少碰到有兴趣在这方面深钻下去的同行,所以文中难免出现错误和遗漏,在此先行声明,欢迎大家指正,不要藏私哦8)
一、树型关系的数据表
不少程序员在进行数据库设计的时候都遇到过树型关系的数据,例如常见的类别表,即一个大类,下面有若干个子类,某些子类又有子类这样的情况。当类别不确定,用户希望可以在任意类别下添加新的子类,或者删除某个类别和其下的所有子类,而且预计以后其数量会逐步增长,此时我们就会考虑用一个数据表来保存这些数据。按照教科书上的教导,第二类程序员大概会设计出类似这样的数据表结构:
类别表_1(Type_table_1)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
这样的设计短小精悍,完全满足3NF,而且可以满足用户的所有要求。是不是这样就行呢?答案是NO!Why?
我们来估计一下用户希望如何罗列出这个表的数据的。对用户而言,他当然期望按他所设定的层次关系一次罗列出所有的类别,例如这样:
总类别
类别1
类别1.1
类别1.1.1
类别1.2
类别2
类别2.1
类别3
类别3.1
类别3.2
……
看看为了实现这样的列表显示(树的先序遍历),要对上面的表进行多少次检索?注意,尽管类别1.1.1可能是在类别3.2之后添加的记录,答案仍然是N次。这样的效率对于少量的数据没什么影响,但是日后类型扩充到数十条甚至上百条记录后,单单列一次类型就要检索数十次该表,整个程序的运行效率就不敢恭维了。或许第二类程序员会说,那我再建一个临时数组或临时表,专门保存类型表的先序遍历结果,这样只在第一次运行时检索数十次,再次罗列所有的类型关系时就直接读那个临时数组或临时表就行了。其实,用不着再去分配一块新的内存来保存这些数据,只要对数据表进行一定的扩充,再对添加类型的数量进行一下约束就行了,要完成上面的列表只需一次检索就行了。下面是扩充后的数据表结构:
类别表_2(Type_table_2)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历,主要为减少检索数据库的次数
按照这样的表结构,我们来看看上面例子记录在表中的数据是怎样的:
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
10 类别1.1.1 3 010101
……
现在按type_layer的大小来检索一下:SELECT * FROM Type_table_2 ORDER BY type_layer
列出记录集如下:
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
10 类别1.1.1 3 010101
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
……
现在列出的记录顺序正好是先序遍历的结果。在控制显示类别的层次时,只要对type_layer字段中的数值进行判断,每2位一组,如大于0则向右移2个空格。当然,我这个例子中设定的限制条件是最多3层,每层最多可设99个子类别,只要按用户的需求情况修改一下type_layer的长度和位数,即可更改限制层数和子类别数。其实,上面的设计不单单只在类别表中用到,网上某些可按树型列表显示的论坛程序大多采用类似的设计。
或许有人认为,Type_table_2中的type_father字段是冗余数据,可以除去。如果这样,在插入、删除某个类别的时候,就得对type_layer 的内容进行比较繁琐的判定,所以我并没有消去type_father字段,这也正符合数据库设计中适当保留冗余数据的来降低程序复杂度的原则,后面我会举一个故意增加数据冗余的案例。
二、商品信息表的设计
假设你是一家百货公司电脑部的开发人员,某天老板要求你为公司开发一套网上电子商务平台,该百货公司有数千种商品出售,不过目前仅打算先在网上销售数十种方便运输的商品,当然,以后可能会陆续在该电子商务平台上增加新的商品出售。现在开始进行该平台数据库的商品信息表的设计。每种出售的商品都会有相同的属性,如商品编号,商品名称,商品所属类别,相关信息,供货厂商,内含件数,库存,进货价,销售价,优惠价。你很快就设计出4个表:商品类型表(Wares_type),供货厂商表(Wares_provider),商品信息表(Wares_info):
商品类型表(Wares_type)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历,主要为减少检索数据库的次数
供货厂商表(Wares_provider)
名称 类型 约束条件 说明
provider_id int 无重复 供货商标识,主键
provider_name char(100) 不允许为空 供货商名称
商品信息表(Wares_info)
名称 类型 约束条件 说明
wares_id int 无重复 商品标识,主键
wares_name char(100) 不允许为空 商品名称
wares_type int 不允许为空 商品类型标识,和Wares_type.type_id关联
wares_info char(200) 允许为空 相关信息
provider int 不允许为空 供货厂商标识,和Wares_provider.provider_id关联
setnum int 初始值为1 内含件数,默认为1
stock int 初始值为0 库存,默认为0
buy_price money 不允许为空 进货价
sell_price money 不允许为空 销售价
discount money 不允许为空 优惠价
你拿着这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)(待续)
浅谈数据库设计技巧(上)
http://www.knowsky.com/4937.html
说到数据库,我认为不能不先谈数据结构。1996年,在我初入大学学习计算机编程时,当时的老师就告诉我们说:计算机程序=数据结构+算法。尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主,但我还是深深赞同8年前老师的告诉我们的公式:计算机程序=数据结构+算法。面向对象的程序开发,要做的第一件事就是,先分析整个程序中需处理的数据,从中提取出抽象模板,以这个抽象模板设计类,再在其中逐步添加处理其数据的函数(即算法),最后,再给类中的数据成员和函数划分访问权限,从而实现封装。
数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的,由此可见,数据库并不一定是存储在电脑里的数据^_^),里面记录的是该奶牛场的收支账目,程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据结构所采集到的数据量大到一定程度后,出于程序执行效率的考虑,程序员将其中的检索、更新维护等功能分离出来,做成单独调用的模块,这个模块后来就慢慢发展、演变成现在我们所接触到的数据库管理系统(DBMS)——程序开发中的一个重要分支。
下面进入正题,首先按我个人所接触过的程序给数据库设计人员的功底分一下类:
1、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具,他们往往习惯只设计有限的几个表,实现某类功能的数据全部塞在一个表中,各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西,当程序功能有限,数据量不多的时候,其程序运行起来没有什么问题,但是如果用其管理比较重要的数据,风险性非常大。
2、系统学习过数据结构,但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久,他们在设计数据库表结构时,严格按照教科书上的规定,死扣E-R图和3NF(别灰心,所有的数据库设计高手都是从这一步开始的)。他们的作品,对于一般的access型轻量级的管理软件,已经够用。但是一旦该系统需要添加新功能,原有的数据库表差不多得进行大换血。
3、第二类程序员,在经历过数次程序效率的提升,以及功能升级的折腾后,终于升级成为数据库设计的老鸟,第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率,而且其设计的数据库可拓展性较好,当用户需要添加新功能时,原有数据库表只需做少量修改即可。
4、在经历过上十个类似数据库管理软件的重复设计后,第三类程序员中坚持下来没有转行,而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟,从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见,能够预测到未来功能升级所需要的数据,从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。
5、第三类程序员或第四类程序员,在对现有的各家数据库管理系统的原理和开发都有一定的钻研后,要么在其基础上进行二次开发,要么自行开发一套有自主版权的通用数据库管理系统。
我个人正处于第三类的末期,所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时,由于我很少碰到有兴趣在这方面深钻下去的同行,所以文中难免出现错误和遗漏,在此先行声明,欢迎大家指正,不要藏私哦8)
一、树型关系的数据表
不少程序员在进行数据库设计的时候都遇到过树型关系的数据,例如常见的类别表,即一个大类,下面有若干个子类,某些子类又有子类这样的情况。当类别不确定,用户希望可以在任意类别下添加新的子类,或者删除某个类别和其下的所有子类,而且预计以后其数量会逐步增长,此时我们就会考虑用一个数据表来保存这些数据。按照教科书上的教导,第二类程序员大概会设计出类似这样的数据表结构:
类别表_1(Type_table_1)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
这样的设计短小精悍,完全满足3NF,而且可以满足用户的所有要求。是不是这样就行呢?答案是NO!Why?
我们来估计一下用户希望如何罗列出这个表的数据的。对用户而言,他当然期望按他所设定的层次关系一次罗列出所有的类别,例如这样:
总类别
类别1
类别1.1
类别1.1.1
类别1.2
类别2
类别2.1
类别3
类别3.1
类别3.2
……
看看为了实现这样的列表显示(树的先序遍历),要对上面的表进行多少次检索?注意,尽管类别1.1.1可能是在类别3.2之后添加的记录,答案仍然是N次。这样的效率对于少量的数据没什么影响,但是日后类型扩充到数十条甚至上百条记录后,单单列一次类型就要检索数十次该表,整个程序的运行效率就不敢恭维了。或许第二类程序员会说,那我再建一个临时数组或临时表,专门保存类型表的先序遍历结果,这样只在第一次运行时检索数十次,再次罗列所有的类型关系时就直接读那个临时数组或临时表就行了。其实,用不着再去分配一块新的内存来保存这些数据,只要对数据表进行一定的扩充,再对添加类型的数量进行一下约束就行了,要完成上面的列表只需一次检索就行了。下面是扩充后的数据表结构:
类别表_2(Type_table_2)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历,主要为减少检索数据库的次数
按照这样的表结构,我们来看看上面例子记录在表中的数据是怎样的:
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
10 类别1.1.1 3 010101
……
现在按type_layer的大小来检索一下:SELECT * FROM Type_table_2 ORDER BY type_layer
列出记录集如下:
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
10 类别1.1.1 3 010101
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
……
现在列出的记录顺序正好是先序遍历的结果。在控制显示类别的层次时,只要对type_layer字段中的数值进行判断,每2位一组,如大于0则向右移2个空格。当然,我这个例子中设定的限制条件是最多3层,每层最多可设99个子类别,只要按用户的需求情况修改一下type_layer的长度和位数,即可更改限制层数和子类别数。其实,上面的设计不单单只在类别表中用到,网上某些可按树型列表显示的论坛程序大多采用类似的设计。
或许有人认为,Type_table_2中的type_father字段是冗余数据,可以除去。如果这样,在插入、删除某个类别的时候,就得对type_layer 的内容进行比较繁琐的判定,所以我并没有消去type_father字段,这也正符合数据库设计中适当保留冗余数据的来降低程序复杂度的原则,后面我会举一个故意增加数据冗余的案例。
二、商品信息表的设计
假设你是一家百货公司电脑部的开发人员,某天老板要求你为公司开发一套网上电子商务平台,该百货公司有数千种商品出售,不过目前仅打算先在网上销售数十种方便运输的商品,当然,以后可能会陆续在该电子商务平台上增加新的商品出售。现在开始进行该平台数据库的商品信息表的设计。每种出售的商品都会有相同的属性,如商品编号,商品名称,商品所属类别,相关信息,供货厂商,内含件数,库存,进货价,销售价,优惠价。你很快就设计出4个表:商品类型表(Wares_type),供货厂商表(Wares_provider),商品信息表(Wares_info):
商品类型表(Wares_type)
名称 类型 约束条件 说明
type_id int 无重复 类别标识,主键
type_name char(50) 不允许为空 类型名称,不允许重复
type_father int 不允许为空 该类别的父类别标识,如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历,主要为减少检索数据库的次数
供货厂商表(Wares_provider)
名称 类型 约束条件 说明
provider_id int 无重复 供货商标识,主键
provider_name char(100) 不允许为空 供货商名称
商品信息表(Wares_info)
名称 类型 约束条件 说明
wares_id int 无重复 商品标识,主键
wares_name char(100) 不允许为空 商品名称
wares_type int 不允许为空 商品类型标识,和Wares_type.type_id关联
wares_info char(200) 允许为空 相关信息
provider int 不允许为空 供货厂商标识,和Wares_provider.provider_id关联
setnum int 初始值为1 内含件数,默认为1
stock int 初始值为0 库存,默认为0
buy_price money 不允许为空 进货价
sell_price money 不允许为空 销售价
discount money 不允许为空 优惠价
你拿着这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)(待续)
发表评论
-
十步完全理解SQL(转)
2014-01-12 22:27 781本文由 伯乐在线 - 水果泡腾片 翻译自 Lukas Ede ... -
Oracle数据库优化的几点总结(转)
2013-11-10 19:01 951个人理解,数据库性能 ... -
ORACLE-SQL性能优化
2013-07-31 23:11 869ORACLE-SQL性能优化 博客分类: or ... -
SQL语句的解析过程
2013-05-15 21:49 989由于最近需要做一些sql query性能提升的研究, ... -
数据库优化(sql优化)
2012-07-11 21:33 1183数据库优化(sql优化) 1.sql优化: 1.选择最有效的 ... -
(转)浅谈数据库设计技巧(下)
2012-04-24 00:19 1352三、多用户及其权限 ... -
sql优化34条
2012-04-24 00:15 728我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为 ... -
什么是SQL注入式攻击
2012-04-18 19:54 1108什么是SQL注入式攻击? 所谓SQL注入式攻击,就是攻击者把 ... -
大数据量高并发的数据库优化与sql优化
2012-04-15 14:46 12005大数据量高并发的数据库优化 一、数据库结构的设计 ... -
oracle的导出与导入
2012-04-08 01:01 1065C:\Documents and Settings\Admin ... -
Oracle开发人员应该具备的几个资源-入门基础
2012-03-10 00:49 1389很多开发者,舍近求远,愿意花大价钱到书店买Oracle的大头 ... -
收集的几条在oracle中通过connect by prior来实现递归查询
2012-03-10 00:49 1398收集的几条在oracle中通过connect by prior ... -
oracle中 connect by prior 递归算法 -- 理解
2012-03-08 23:10 1058oracle中 connect by prior 递 ... -
大数据量,海量数据 处理方法总结
2012-03-07 00:39 1232大数据量,海量数据 处理方法总结 最近有点忙,稍微空闲下 ... -
海量数据处理
2012-03-07 00:37 885海量数据 ... -
Oracle 游标使用大全
2012-03-04 15:54 901[转] Oracle 游标使用大全 我们将讨论各种用于访问 ...
相关推荐
### 数据库设计技巧经验浅析 #### 一、引言 数据库设计是软件开发中至关重要的环节,良好的数据库设计不仅能确保数据的有效存储与快速检索,还能为后续的应用扩展打下坚实的基础。根据“3分技术,7分经验”的原则...
浅谈数据库设计技巧.mht
通过学习和实践这些数据库设计技巧,程序员能够更好地应对各种复杂的业务场景,构建出高效、可靠的数据存储系统。在实际工作中,不断总结经验,持续学习新的数据库技术和最佳实践,是保持竞争力的关键。
老程序员工作笔记,五年以上的开发人员在工作中积累的经验,可以帮组很多新手,你值得拥有。
### 数据库设计技巧详解 #### 一、引言与背景 数据库设计是现代软件开发中的核心环节之一。本文从数据结构的重要性入手,探讨了不同类型的程序员在设计数据库时的表现,并提出了针对特定场景的设计技巧。 #### 二...
【数据库设计技巧】 数据库设计是IT领域中至关重要的一部分,它涉及到如何有效地组织和存储数据,以便于高效地访问和管理。本文将探讨一些数据库设计的关键技巧,尤其关注SQL语句的使用。 首先,数据结构是数据库...
一个良好的数据库设计不仅需要满足数据存储的需求,还要保证数据的完整性和准确性,同时也要兼顾系统的查询速度和执行效率。在设计过程中,应考虑到应用需求和开发团队的技术能力,合理选择开发工具和开发环境。...
在索引的创建过程中,需要根据数据访问模式和业务需求,合理选择索引类型,并在索引使用原则和建立技巧上有深入的理解和掌握,从而优化数据库性能。 在结束语中,作者指出数据库设计是一个系统化的过程,涉及到多个...
【Oracle 数据库表设计技巧】 在Oracle数据库设计中,表的构建是至关重要的基础工作,对数据库性能的影响深远。良好的表设计能显著提升数据库效率。本文主要针对Oracle初学者,介绍一些实用的设计技巧。 首先,...
这些知识点不仅涵盖了SQL Server数据库的核心功能和技术,还包括了数据库设计、开发和维护的各个方面,对于任何希望深入理解和应用SQL Server数据库技术的专业人士而言,都是不可或缺的参考资料。
同时,优化工作需要在数据库设计阶段就开始考虑,以最小的代价获得最大的性能收益。在实际工作中,DBA和资深程序员应当利用他们的经验,通过分析SQL语句的执行计划,不断尝试优化方案,最终实现查询效率的最大化。
### DB2 数据库调优浅谈 #### 数据库调优的视角 在进行数据库调优时,不同的视角可能会带来不同的解决方案。通常来说,可以从以下几个方面考虑: - **应用优化**:针对应用程序本身的优化,比如查询逻辑、事务...
"浅谈海量数据处理技巧" 本文主要讨论海量数据处理的技巧,包括数据导入、数据库设计、索引创建和分表存储等方面。 数据导入是海量数据处理的第一步。文中提到三种将文本数据导入 SQL Server 数据库的方式:通过...
文章指出,Oracle数据库技术的教学内容应从基础概念入手,如关系数据库理论、数据库体系结构、以及数据库的启动与关闭等,然后逐步过渡到Oracle数据库核心的操作技能,包括SQL的使用、查询技巧、数据管理及安全等...
在数据库应用开发过程中,经常遇到的软件运行速度瓶颈往往集中在大量查询、统计和分析等数据库操作上。为了提升数据库的性能,数据库优化是一个重要的手段,其中应用层面的优化主要依赖于索引优化。 索引对于数据库...
本篇文档题为“浅谈如何优化SQL语句提高数据库系统效率”,旨在探讨在数据库系统中如何通过优化SQL语句来提升整体性能。文档中提到了多种SQL优化的策略和方法,涵盖了查询优化、索引使用、查询语句的设计原则等方面...