The database won't become "fragmented," because it's built chronologically: each new post is added to the end of the existing stack of posts. This is reflected in the unique number each post is assigned. A "thread" has no discrete existence; it's assembled on the fly out of the database of chronologically stacked posts by reading the information contained in the initial post and going from there.
I think it works like this: each post in a thread is linked to any replies, and to the post to which it is a reply.
So the
first post in a thread is, say, #91. Included in that entry is the information that that post begins a thread, and that the thread is located in, say, the Lounge.
When a reply is made—say, post #110—
that entry includes the info that post #110 is a reply to post #91, and post #91's entry is updated to include the info that there is a reply to it: post #110. Post #121 is
also a reply to post #91; it follows post #110 not because there's any connection between the two, but because it occurred later chronologically. And so on, to the end of the thread.
When the server is asked to return that thread, the software pulls the initial post from the database, since that's how the thread is actually identified—by the number of the initial post. The software notes that post #91 has 2 replies—post #110 and post #121—so it grabs
those posts from the database and adds them to the thread. And so on, to the end; the entire thread is "assembled" like beads on a string: the beads aren't "stored" according to which necklace they belong on; they're simply stored in the order they were made.
Now, if cyn decides to move this thread from the Lounge to FineTunedMac Feedback,
all that actually changes is that post #91's database entry is changed to reflect its new location. The rest of the thread follows automatically, because the entire thread is assembled on the fly from pointers included within the individual posts, starting with the original post.
Or something like that.
