Anyway! The relational model uses tables to model all data. Though you can squeeze a comment tree into a relational data mode any number of ways, it is most clearly expressed by a hierarchical model as in XML, S-exprs or a tree data type in your favorite language.
So I'm not saying it can't be expressed as relational data, what I mean is that that representation is not its most natural or useful form.
At work I use a query like:
select s1.id, s2.id, s3.id, s4.id ...
FROM subject s1
LEFT JOIN subject s2 WHERE s2.id=s1.parent
LEFT JOIN subject s3 WHERE s3.id=s2.parent
LEFT JOIN subject s4 WHERE s4.id=s3.parent
....
WHERE s1.id=?
So, while you can model a tree as relational data, it's not a good match.
http://www.evolt.org/working_with_hierarchical_data_in_sql_u...
This allows all children (or parents) to be fetched in a single query. A suitable "order by" clause also groups them together for easier processing in one pass.
The cost is the same as any denormalisation - additional updates and integrity issues - so it isn't a no-brainer but it's probably a win in most such situations.
2) If you do decide to use the database, you can increase the write speed of the nested sets model by leaving large gaps between the left and right values.
That is, if the single child of the root node has left and right values of 0 and 1000, and you insert another child, you give it left and right of 1000 and 2000, and update the parent.
Then you'll only have to renumber if you get a wicked long thread.