关于数据库的一些疯狂想法
2013-08-12 16:26
337 查看
最近上班,无事可做。并非自己已经是大牛,而是学的东西太多,反而不好下手。
突然想到了林林总总的问题。
现在的应用越来越大,需求越来越奇怪。因此,传统的研发模式已经难以满足变化着的需求,那么现在的开发采用的就是敏捷。
敏捷解决了需求变更的问题,却带来了新的问题:
1、数据表越来越庞大;
2、数据表维护性越来越差;
3、数据表中存在不必要的冗余。
以上只是和数据库有关的问题,其他问题本文不列举。
那么如何解决这个问题呢?
至少目前还没有一个规范的方案。
在此将自己的想法列举出来,供自己启发,一起共勉。
在一个大型的数据库中,表和表之间的关系比较复杂。一个不熟悉系统的人是很难理清其中的相互关系。在此,我将表之间的关系重新分类:
注:定义一下表:A,B,C,D,E,F,G,H,I,J,。。。。Z,如果需要,再定义A1,。。。Z1,A2,。。Z2,。。,An,Zn
1、链式关系
链式关系指几张表中表每两两相连,类似数据结构中的链表。例如 A-B-C-D-E
2、父子关系
父子关系只很多表都和其中一张表有关联,但他们彼此却没有关联,例如:A-B,A-C,A-D,A-E
3、其他关系
待定。。
可以看处,数据库中的表间关系和数据结构中的树很相似,我们也发现,每个树都有根,同样的道理,每个数据库中都有"根“表。但数据库并非简单的树结构,仔细想想可以发现,大型的数据库中,往往存在一些独立的表,比如购物网站上的友情链接表F等。那么,更准确的说,数据库表间关系是数据结构中的森林。
那么,我们怎样让这个森林更加合理呢?
森林中的树有大有小,有的可能是一张独立的表,有的可能只是两三张表组合而成,而有的,可能是有十几张表甚至几十张表组成的复杂关系。(这里的关系不是特指一对一,一对多,多对多,而是泛指所有有关联的表的关系,是一种表间依赖)那么,总结自己的经验和理解,提出以下几种方式优化我们的数据库:
1、对于单表
这里所指的单表,是只不可能或很可能不会受其他需求,其他表约束的表,比如我们刚刚提到的友情链接表F,我们定义F 的表结构如下:
F(url,name,logo_image,type)也许一开是我们就能定义链接的属性:链接地址,名称,log图片,链接类型。这样,就已经包含了一个基本的友情链接需要的参数,那么,就可以展示我们的友情链接。可是随着业务的发展,友情链接越来越多,而且有一些过期的链接,现在怎么办?可以增加字段,begin_at,end_at,is_show,大致意思就是展示友情链接的开始和结束时间,是否显示该链接等。目前来看,这张表变得较之前更复杂了,可是它还是一张表,没有产生多余的表,这样的表我们叫做死表。
还有一种单表,会慢慢演化成多张表。
很多网站都提供了邮件订阅的服务,订阅一个网站的该服务并不许要成为该网站的用户,只需要提供你的Email地址就可以。那么这张表也变得非常简单:E(email,count),我们要记住,这个表只提供给哪些Email发邮件的服务,并且记录发邮件成功的次数,而不做其他多余的任何事情!!!如果用户退订了该订阅,我们为了使表E提供单一的功能,决定增加表E1(email,count),将退订的用户放置在这表中,仔细一看,E 和E1 是没有任何关系的,因此E 还是一张死表。就算E1中的地址再次订阅该服务,也只是在两张表之间交换数据而已。那么你可能会问,E
和E1 可能有关系吗?答案是:YES
在复杂的需求面前,很多事情都不是我们想象的那么简单,比如需要显示该网站一共成功发出多少封邮件,(肯定得包含E1中的数量吧),他们之间就建立了一种弱联系。
备注:可能细细分析来看,这个例子并非正确,但是在实际应用中的确存在这样的情况,我们称这种表为活表。
2、对于少量表组成的关系
当表少于5张组成的树形关系中,通过分析不难分析出是否符合3范式,或者可以优化使其满足3范式,使其只具有1对1的依赖,并确定好树的“根“表。比如著名的学生-课程-老师的关系表:
S(name),T(name),C(name),S_C(S_ID,C_ID),T_C(T_ID,C_ID)很容易看出该关系满足3范式。如果需求增加,很清楚的可以在S,C,T表中增加响应的字段,并不复杂。
3、对应复杂的树
复杂的树可能是由几十张表甚至更多的表组成,那么,我们如何管理这么多表及其关系呢?答案是:分组
所谓分组,就是将联系紧密的关系和联系不紧密的关系区分开来。看下面的例子:
A-B-C-D,B-E-F-G-H C-I-J-K,D-L-M-N,可以看出EFG和B的关系密切,和CD的关系稀疏,那么我们可以将B-E-F-G看成一个分组,C-I-J-K看成另一个分组,对他们各个组间进行优化,如果这样递归下去,就能够得到一个相对合理的表结构(此处说相对合理,是因为本人目前没有做过相关测试和系统分析)。
总的来说,复杂的表都是由简单的表组成,从简单开始,逐步规划自己的数据库结构。
注:本文并没有任何实际根据,只是作者记录所见所想,用于互勉。如有任何问题,欢迎讨论。
突然想到了林林总总的问题。
现在的应用越来越大,需求越来越奇怪。因此,传统的研发模式已经难以满足变化着的需求,那么现在的开发采用的就是敏捷。
敏捷解决了需求变更的问题,却带来了新的问题:
1、数据表越来越庞大;
2、数据表维护性越来越差;
3、数据表中存在不必要的冗余。
以上只是和数据库有关的问题,其他问题本文不列举。
那么如何解决这个问题呢?
至少目前还没有一个规范的方案。
在此将自己的想法列举出来,供自己启发,一起共勉。
在一个大型的数据库中,表和表之间的关系比较复杂。一个不熟悉系统的人是很难理清其中的相互关系。在此,我将表之间的关系重新分类:
注:定义一下表:A,B,C,D,E,F,G,H,I,J,。。。。Z,如果需要,再定义A1,。。。Z1,A2,。。Z2,。。,An,Zn
1、链式关系
链式关系指几张表中表每两两相连,类似数据结构中的链表。例如 A-B-C-D-E
2、父子关系
父子关系只很多表都和其中一张表有关联,但他们彼此却没有关联,例如:A-B,A-C,A-D,A-E
3、其他关系
待定。。
可以看处,数据库中的表间关系和数据结构中的树很相似,我们也发现,每个树都有根,同样的道理,每个数据库中都有"根“表。但数据库并非简单的树结构,仔细想想可以发现,大型的数据库中,往往存在一些独立的表,比如购物网站上的友情链接表F等。那么,更准确的说,数据库表间关系是数据结构中的森林。
那么,我们怎样让这个森林更加合理呢?
森林中的树有大有小,有的可能是一张独立的表,有的可能只是两三张表组合而成,而有的,可能是有十几张表甚至几十张表组成的复杂关系。(这里的关系不是特指一对一,一对多,多对多,而是泛指所有有关联的表的关系,是一种表间依赖)那么,总结自己的经验和理解,提出以下几种方式优化我们的数据库:
1、对于单表
这里所指的单表,是只不可能或很可能不会受其他需求,其他表约束的表,比如我们刚刚提到的友情链接表F,我们定义F 的表结构如下:
F(url,name,logo_image,type)也许一开是我们就能定义链接的属性:链接地址,名称,log图片,链接类型。这样,就已经包含了一个基本的友情链接需要的参数,那么,就可以展示我们的友情链接。可是随着业务的发展,友情链接越来越多,而且有一些过期的链接,现在怎么办?可以增加字段,begin_at,end_at,is_show,大致意思就是展示友情链接的开始和结束时间,是否显示该链接等。目前来看,这张表变得较之前更复杂了,可是它还是一张表,没有产生多余的表,这样的表我们叫做死表。
还有一种单表,会慢慢演化成多张表。
很多网站都提供了邮件订阅的服务,订阅一个网站的该服务并不许要成为该网站的用户,只需要提供你的Email地址就可以。那么这张表也变得非常简单:E(email,count),我们要记住,这个表只提供给哪些Email发邮件的服务,并且记录发邮件成功的次数,而不做其他多余的任何事情!!!如果用户退订了该订阅,我们为了使表E提供单一的功能,决定增加表E1(email,count),将退订的用户放置在这表中,仔细一看,E 和E1 是没有任何关系的,因此E 还是一张死表。就算E1中的地址再次订阅该服务,也只是在两张表之间交换数据而已。那么你可能会问,E
和E1 可能有关系吗?答案是:YES
在复杂的需求面前,很多事情都不是我们想象的那么简单,比如需要显示该网站一共成功发出多少封邮件,(肯定得包含E1中的数量吧),他们之间就建立了一种弱联系。
备注:可能细细分析来看,这个例子并非正确,但是在实际应用中的确存在这样的情况,我们称这种表为活表。
2、对于少量表组成的关系
当表少于5张组成的树形关系中,通过分析不难分析出是否符合3范式,或者可以优化使其满足3范式,使其只具有1对1的依赖,并确定好树的“根“表。比如著名的学生-课程-老师的关系表:
S(name),T(name),C(name),S_C(S_ID,C_ID),T_C(T_ID,C_ID)很容易看出该关系满足3范式。如果需求增加,很清楚的可以在S,C,T表中增加响应的字段,并不复杂。
3、对应复杂的树
复杂的树可能是由几十张表甚至更多的表组成,那么,我们如何管理这么多表及其关系呢?答案是:分组
所谓分组,就是将联系紧密的关系和联系不紧密的关系区分开来。看下面的例子:
A-B-C-D,B-E-F-G-H C-I-J-K,D-L-M-N,可以看出EFG和B的关系密切,和CD的关系稀疏,那么我们可以将B-E-F-G看成一个分组,C-I-J-K看成另一个分组,对他们各个组间进行优化,如果这样递归下去,就能够得到一个相对合理的表结构(此处说相对合理,是因为本人目前没有做过相关测试和系统分析)。
总的来说,复杂的表都是由简单的表组成,从简单开始,逐步规划自己的数据库结构。
注:本文并没有任何实际根据,只是作者记录所见所想,用于互勉。如有任何问题,欢迎讨论。
相关文章推荐
- 关于数据库主键生成策略的一些想法
- 关于瀑布流布局的一些想法
- 关于代码重构和UT的一些想法,求砖头
- 关于系统设计的一些想法
- 关于解压缩的一些想法
- 关于wayos授权验证及wayos破解的一些想法
- 关于一些android数据库的创建
- 关于 设计模式的一些想法
- 关于runjs的一些想法
- 关于redis和memcached的一些想法
- 关于数据库测试数据的一些心得
- 关于web2.0的一些想法
- 关于利用python进行验证码识别的一些想法
- 关于聚类算法的一些个人想法
- 关于DCLP实现的单例模式的一些想法
- 关于软件规模代码行(LOC, Line of Code)度量的一些想法
- RFC32 关于SRI所提议的实时时钟的一些想法
- 关于数据库连接的一些基础复习
- 关于反模式、设计和复用的一些想法
- 2017/09/25 关于cache和axi的一些想法