It's a little more complicated.

When you store the tree on the DBMS, you have some algorithtms to do it well. For Example, the Nested Set (check the link up).

In that algorithm, the nodes are stored in a hierarchy that does not have any information about the votes.

So, you have a perfect tree, but with the first vote, you must update all the structure to reflect the new order of the child.

Nested set is great for speed reading, but not for writing often.

Sorry if I'm not very clear.

I was testing rails plugins : acts_as_nested_set and acts_as_better_nested and all have the same problem.

I used a slightly different approach of combining acts_as_tree (for faster updates/inserts) and added a dotted_id for faster reads. The dotted id is a string,as in 0001.0002.0007. Index this column and its fairly fast. The obvious limitation this approach creates is the depth of your comment tree. approx =dotted id col size/#of digits in max pk -1. Not an issue for many. When Im updating the hierarchy , I update root of the hierarchy being moved and then a single UPDATE to update the dotted ids in that subtree. If you are using MySQL, then the max length of a column that can be indexed is also limited. Don't remember the exact length.

By its nature this site does not generally have deep nesting. Adjacency lists are inefficient with deep, narrow nesting. I think that performance would be acceptable with that approach.

However, nested sets are more elegant. I believe the best approach would be to do the reordering in the application. Retrieve the comments in arbitrary order (probably chronological), and sort the siblings by votes just before you render.