关于数据库的一些疯狂想法

最近上班，无事可做。并非自己已经是大牛，而是学的东西太多，反而不好下手。

突然想到了林林总总的问题。

现在的应用越来越大，需求越来越奇怪。因此，传统的研发模式已经难以满足变化着的需求，那么现在的开发采用的就是敏捷。

敏捷解决了需求变更的问题，却带来了新的问题：

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看成另一个分组，对他们各个组间进行优化，如果这样递归下去，就能够得到一个相对合理的表结构（此处说相对合理，是因为本人目前没有做过相关测试和系统分析）。

总的来说，复杂的表都是由简单的表组成，从简单开始，逐步规划自己的数据库结构。

注：本文并没有任何实际根据，只是作者记录所见所想，用于互勉。如有任何问题，欢迎讨论。