在多个页面上分离嵌套讨论的最佳方法是什么 - 对于Web应用程序？

Question

我正在为PHP/MySQL应用程序设计一个线程消息显示 - 就像Slashdot或Youtube上的评论 - 我想知道如何去订购评论并将其分成多个页面，以便您可以有20条评论一个页面，但仍然有他们嵌套。

我的应用程序中的注释可以嵌套无限级别，并且此结构使用我认为是Adjacency Relation表的表示来表示，该表是包含具有任何上升/下降关系的每对行的单独表。该关系表具有CHILDID，PARENTID和LEVEL，其中2级意味着“曾祖父母”，等等。

我的问题是最终用户的可用性和构建高效DB查询的实用性之一。我已经考虑这些选项：

• 劈裂成日期的网页，无论在树中的位置，从而在一定日期范围内所有评论都一起出现，即使他们不与父母出现。任何在与其父母相似的时间发布的评论都会显示在同一页面上，在这种情况下，我们可以将它们显示为“嵌套”，但会有与父母成为孤儿的评论。这可能是可以接受的 - 这是在YouTube评论中完成的方式 - 比其父母晚得多的评论不会与其父母出现在同一页面上（如果父母不在最新的页面上），而是与其他最新评论。

• 按照像遍历树的顺序检索节点。虽然兄弟姐妹仍然可以按日期排序，但这会优先考虑树结构而不是日期。这样做的好处是，即使该父母是最近评论中的多个页面，回复也始终与其父母（即他们正在回复的评论）一起放置。这就是在诸如icanhascheezburger博客这样的应用程序上完成的事情。我不喜欢关于它的一些事情，比如每个人都试图添加对最大树分支的答复的方式。

• 第三个选择是像Slashdot那样做，它不会将注释分成页面，但有一棵大树 - 为了保持页面大小可管理，它开始剔除低评分注释。

我认为第一个将是给我的关系表最简单的数据库查询，但会对其他想法开放。

所有这三种类型的系统都会以某种方式限制嵌套层次 - 这很容易做到，一旦我们在X层次上递归，其他所有东西都可以像兄弟姐妹一样组合在一起。例如，YouTube评论只能呈现一个级别。其他系统有时会在5个左右的水平后说“嵌套水平超标”。

Answer 1

我认为，之所以你想嵌套的评论在一切都是因为你的用户往往希望通过在同一时间关注单个线程读取。也就是说，你有理由相信用户会创建连贯一致的思路线索，并且/或者在一个线程中讨论的内容会让一些用户感兴趣，而不是其他人感兴趣。

如果是这样的话，我不知道为什么你会想要在日期之间随意分割一个线程（选项1）。使用单个页面筛选低评级评论（选项3）似乎有点苛刻，可能会阻止用户发表评论。如果你有像SlashDot这样的观众群体，这可能是一件好事，但对于访问率更高的网站来说，这可能是不理想的。

也许你可以拥有类似于选项2的东西，所有线程都在同一页面上，但是如果一个线程开始变得太长，它会被汇集到一个单独的链接，将用户带到专用于该线程的页面。或者，可以减少长线程以显示其主题行和作者，每个主题行和作者又链接到线程的专用页面中的适当位置。

我怀疑用户在最大的线程中发布无关注释的倾向是用户不希望被卷动来寻找线程末尾或找到更合适的线程的烦恼。通过自动压缩长线程，让所有线程的根目录显示在可管理长度的单个页面上，用户可以轻松扫描感兴趣的线程并根据需要添加到线程中。

Answer 2

我想你需要的是将分层数据存储在数据库中。 你应该与此文章开始： Article at sitepoint Article at MySQL's website