怪僻游戏现在是玩得如火如荼,于是有很多人出来,打算统计这个病毒传播的途径,本来这也算是一桩雅事。只是病毒传播的速度远远超出人们的预料,不用工具是不行了。
最初的设想,是画个漂漂亮亮的图,比如用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多个节点的数据,如果运气不好,甚至可能需要修改几乎所有的记录,删除也是一样,而当需要进行各种查询统计操作的时候,依然令人感觉到复杂与效率底下。如果每一个操作,都需要锁定整张表的时候,这样的数据库设计,就是彻底失败的!
大家自己比较比较吧。