I don’t see why “searching” is much simpler:
- If there were separate Posts and Topics, and the UI were like Discourse, then the main page selects topics (not posts).
- Or if the UI were like SE’s, then the main page selects topics joined to one post (either the topic’s first post, or its “active” i.e. most-recently-edited post).
- If you’re on a page like this one (i.e. showing the details of one selected topic) then the back end selects the topic plus all posts associated with that topic.
Still, have it your way and I’m glad you understood what I was saying at least – or do you?
Having extra stuff in posts (e.g. Title and IsMeta in answer records) means the database doesn’t (even) satisfy second normal form.
I’m all for breaking rules, am I not, but if you’re sure you want to do that this early I imagined more reasoning than this,
I thought about splitting into a Answers table and and QuestionsTable but doing it in the same table lets comments have a PostsId instead of a QuestionsId and a AnswersId. Meta posts are denoted by the IsMeta column. Still unsure on community wiki/FAQ posts.
Maybe we’ve just got different ideas about DB design – mine’s too purist or something.
Given What kind of database should we use? I thought the schema wouldn’t attempt to support n-level trees, yet this one does.
As you say, maybe that’s right though.