关于评论系统有限层及无限层评论的肤浅认知

由于本人并未开发过评论系统，也不是很了解其中原理，此文仅作为个人认知，诚恳接受大家的批评指正。

本文提到的有限层评论其实仅限于单层或者双层。

一、单层评论的优缺点及中庸之道
优点：存储结构简单，无需多余的表连接，提取数据快。
缺点：多数情况下无法看出当前评论是针对哪个评论而发出的评论，也就是说无法看出当前评论的父节点。

中庸之道：
1、加入引用（quote）形成表现层的层次结构，但是在存储上存在2种方式：
1.1、引用评论的ID；
1.2、直接引用内容。
前者的缺点是如果允许用户修改或者删除评论，那么可能出现下面的评论内容很奇怪或者设计不当出现后续内容无法显示等问题，当然引用ID会在根据ID读取内容上可能存在性能问题，由此可能牵扯出是否后台设计上已经是一种树形结构的多层评论系统的设计；
后者的便捷之处就是直接提取内容，如果这种引用层次非常深，可能简洁及美观上值得商榷同时需要考虑数据的存储方式，当然也存在上面提到的前一种情况。
2、使用@提示：这样虽然不能解决评论层次问题，但是可以明确表明我想针对谁的评论进行评论。当然如果系统支持@提醒，那么更好了，如果不支持@提醒，那么还要@有什么用呢？

2、无限层评论的优缺点及中庸之道
此种形式表现上非常形似引用。
优点：结构清晰，系统可以直接针对这种结构有针对性的提醒用户。
缺点：存储结构复杂，提取数据时在效率上没有单层高，将所有的困难都抛给了设计人员：删除评论的处理、某条评论所有子评论的统计、评论路径的显示等等。
中庸之道：
可以根据实际的情况选择合适的存储结构：邻接表？枚举路径？闭包表？（具体请参阅《SQL反模式》），再者现在多数数据库都支持公用表表达式（CTE），这是一种使用临时命名的结果集，可以减少以往使用游标递归锁表时间，其效率较游标形式高出许多。
同时无限层也存在这引用评论这种形式的一些弊端。

现在主流使用单层、引用、@并存的方式，既可以增加用户的可选择性，又可以适度的提高表现的形式，同时还可以提醒用户。

以上是个人一些肤浅的看法，向各位老师学习。