Instead of this from Schema Proposal Round 2 …
**Posts** UsersId (bigserial) CommunitiesId (bigserial) Title (Text 255 Default NULL) Body (Text) IsMeta ParentId etc. **Comments** UsersId (bigserial) PostsId (bigserial) Body (Text) etc. **PostsTags** PostsId (bigserial) TagsId (bigserial) UNIQUE CONSTRAINT (PostsId,TagsId)
… I propose …
**Topics** CommunitiesId (bigserial) Title (Text 255 Default NULL) IsMeta etc. **Posts** UsersId (bigserial) Body (Text) TopicsId # instead of ParentId etc. **Comments** UsersId (bigserial) PostsId (bigserial) # as before Body (Text) etc. **TopicsTags** TopicsId (bigserial) # instead of PostsId TagsId (bigserial) UNIQUE CONSTRAINT (TopicsId,TagsId)
It extracts (into a Topics table) stuff that’s applicable to a whole topic and not to a specific “posts” (and certainly not to any answer) within the topic.
That’s assuming a structure like SE’s and/or Discourse’s – i.e. a list of topics each containing a list of posts (of which the first might be a question).
Having a ParentId in the Post record would allow for n-level trees – each answer is itself a topic – which is an advanced and potentially complicated feature, perhaps for a later feature if ever.
Having a Topics table makes the existence of “Topics” explicit and gives you somewhere to put things (like a title, and whether it’s meta) and to reference things (like tags) which belong to the whole topic and not e.g. to an answer.