因此，让我们一个基本的例子。我们有一个的评论模型，它看起来有点像这样：
| create table comments ( id SERIAL PRIMARY KEY, message VARCHAR, author VARCHAR, parent_id INTEGER REFERENCES comments(id) ); insert into comments (message, author, parent_id) values ('This thread is really cool!', 'David', NULL), ('Ya David, we love it!', 'Jason', 1), ('I agree David!', 'Daniel', 1), ('gift Jason', 'Anton', 2), ('Very interesting post!', 'thedz', NULL), ('You sir, are wrong', 'Chris', 5), ('Agreed', 'G', 5), ('Fo sho, Yall', 'Mac', 5); |
我们现在所做的，是建立一个基本的评价模型。我们的消息，笔者父评论（这是可选的）。现在，让我们来学习如何使用递归查询可以轻松地重新订购本datd中，由id升序排序。
| WITH RECURSIVE cte (id, message, author, path, parent_id, depth) AS ( SELECT id, message, author, array[id] AS path, parent_id, 1 AS depth FROM comments WHERE parent_id IS NULL UNION ALL SELECT comments.id, comments.message, comments.author, cte.path || comments.id, comments.parent_id, cte.depth + 1 AS depth FROM comments JOIN cte ON comments.parent_id = cte.id ) SELECT id, message, author, path, depth FROM cte ORDER BY path; |
很甜蜜吧？哦，等等，有困惑？所以我一直在寻找的查询更复杂的是一大堆惊人的bug.
pgexperts为我们指向正确的道路。
现在，我不会钻到太多，因为有更好的教程，在此模式中处理递归查询，但我们完成了我们的结果。
我们要处理一个巨大信息集，并且有些评论有将近几千个回复。如果99%的评论都只有100个回复，那么将他们放入内存中并不是什么问题，但当他们开始增加时，我们最终会浪费很多时间。PGSQL中的递归查询可以让我们很简单的把这项工作交给数据库（有时候他们处理的比我们快的多），并且给我们节省了很多花费在网络传播和web处理的时间和资源。
有一个例子可以让你更直观的理解他是多么的高效，我们曾经见过仅在大型数据库的SQL处理时间这一项上（返回25个结果，而不是1000个）就将近节省了500%的时间。这甚至没有包括我们在程序级上的花费。是的，没错，这些SQL语句仅在数据库层上就比其他数据库快5倍
总而言之，作为一个MySQL的拥护者，我对Disqus使用PostgreSQL所达到的性能，规模，以及灵活性表示十分震惊。我十分期待去发现通过这个平台我们还能做什么，去寻找还在等待我们的挑战。
