If this is feasible, I'd also like to request that guildportal take out the reply limit for sites that are being paid for.

The limit use to be 200, it's only been changed to 100 in the last month or so. I too would like to see it either brought back to 200 or unlimited.

I'll bump the limit back up to the previous value of 200 with the next code push.  There is no limit to the number of posts or topics that you can have overall on your sites... There's just a limit on the number of posts per topic.  It has something to do with limitations on the back-end data store (SQL Server 2000), and how while we only display a page of replies at a time, the actual query pulls them all back.  So a topic with 1,000 replies actual does the work of pulling all 1,000 replies back from the database and passing them to the web server, even though we only display around 20.  There are mechanisms in the database to pull a certain number of records back, but the sorting algorithms built into the database server to perform that kind of manipulation can in many cases be more detrimental to performance overall than the current implementation.

I'll take a look at some design options though, since this seems to be a growing concern.

Graxk, I'm not sure what you mean by splitting the thread per number of replies... The database design we're using is relational to the third normal form, though, if that has any bearing on what you're trying to convey.

Ahh, sorry, re-reading what I typed even I got confused. 

What we did was sort of cumbersome for smaller threads, so I would understand if you and your team viewed it and passed it to the wayside for better performance overall.

We had a database that tracked a "topic" and assigned that topic a numerical ID.  The first database held a "parentID" and a "replyID".  The "parentID" was the ID that was assigned to the topic and the "replyID" held the data for all the replies in a topic.  We capped the reply ID to something like 25 replies (I think that was our display cap) and when the 25 was met it created another database for the next 25 replies and created a new element in the first database using the same "parentID" and using the next available "replyID".

When someone wanted to view a set of replies by clicking the thread name on their website we ran a query to see how many replies total there were for the |1|2|3|4|, etc.  When they clicked a number we just went to that number result in the query for "SELECT replyID WHERE parentID = #".  Eh, I'll stop going into detail since this part is rather trivial.