奇蠢无比的数据库设计一例

怪僻游戏现在是玩得如火如荼，于是有很多人出来，打算统计这个病毒传播的途径，本来这也算是一桩雅事。只是病毒传播的速度远远超出人们的预料，不用工具是不行了。

 

最初的设想，是画个漂漂亮亮的图，比如用MindMap Manager之类的工具搞一个： 引爆“怪癖”病毒之看图说话。这么搞也是人力有时而穷啊，结果我今天就看到了一个“高手”，打算用数据库来统计这个传播的信息。 玩得都那么有技术含量:用数据库保存"怪癖图"。在经过仔细研究之后，我发现，这是一个奇蠢无比的数据库。而且，这个设计还不是mornlee本人的设计，竟然大有来头：Managing Hierarchical Data in MySQL 。

 

为什么要说这个设计愚蠢呢？让我们从头说起吧。

 

首先明确我们讨论的范畴：如何通过关系型数据库的二维表，保存树状图信息？当然，我们不能仅仅考虑将数据保存起来，还要考虑添加、修改、删除、查询、统计等等工作的方便性与执行效率。而这嵌套集合模型(Nested Set Model)简直可以算是一无是处。

 

这Mike Hillyer之所以反对之前的邻接列表模型(Adjacency List Model)，还是有道理的。因为假设在一个节点信息中，仅仅记录了其父节点的ID号，那么当我们试图查询一个节点的多级子节点集合，或者第N层父节点时，就会非常吃力。面对这样的吃力，一般来说，我们都会对这个模型进行改进，添加一些信息。在我曾经做过的数据库设计中，我至少会添加这样两个字段：

PathInfo   varchar(2000)

LastId       int

在PathInfo中，我会存放一个路径信息，比如第一级节点，PathInfo即为N，N可以为1～x，第二级节点，PathInfo即为N,M，同上，第三级节点：N,M,L同上。假设有一个节点1,2,1，我们想在这个节点下加一个子节点，那么这个新节点的PathInfo，就应该是1,2,1,1，然后，我们还要将父节点的LastId，从0改变为1，下一次我们想要再增加一个节点的时候，就会计算出PathInfo为1,2,1,2。依此类推。

 

在我们添加了这两个字段之后，可以很方便的进行各种查询，添加，删除，修改，统计等等操作。再回过头来看这所谓的嵌套集合模型，真是令人吃惊，每次添加一个新的节点，都要同时修改N多个节点的数据，如果运气不好，甚至可能需要修改几乎所有的记录，删除也是一样，而当需要进行各种查询统计操作的时候，依然令人感觉到复杂与效率底下。如果每一个操作，都需要锁定整张表的时候，这样的数据库设计，就是彻底失败的！

 

大家自己比较比较吧。