这两种模式中的哪一种更具可扩展性？

Question

我正在玩弄两种模式，但我无法决定哪种模式更具可扩展性。该模式用于问答，它内置在 MySQL 中。人们发布问题/答案并喜欢/不喜欢/最喜欢的问题和答案。一个问题可以有很多答案/喜欢/不喜欢，一个答案也可以。

要向用户阅读问题，两种模式都需要相同数量的连接，但连接的处理方式不同：

架构 1

questions(id, title, body, userId)
questionLikes(id, questionId, userId)
questionDislikes(id, questionId, userId)
quetionComments(id, questionId, body, userId)
answers(id, questionId, body, userId)
answerLikes(id, answerId, userId)
answerDislikes(id, answerId, userId)
answerComments(id, answerId, userId, body)
favourites(id, questionId, userId)

这更规范化，更容易开发，但可扩展？似乎有很多重复的信息。抓取问题的连接序列是针对用户的（我们希望包括他的喜欢/不喜欢活动）

select question
join answers
join questionLikes
join questionDislikes
join questionComments
join favouites 
join answers to answerLikes
join answers to answerDislikes
join answers to answerComments (multiply answer joins by number of answers)

架构 2

posts(id, postTypeId, userId, title, body)
postTypeId(id, postType)
comments(id, postId, userId)
votes(id, voteTypeId, userId)
voteTypeId(id, voteType)

这不太规范化和紧凑，似乎可以更好地扩展，自联接和其他开发问题（条件验证）会让人头疼。抓取问题的连接序列是

select question and its answers in the same read using where @id for question, and @questionId for answers; each row, join the following:
join votes on as likes on voteType 1
join votes as dislikes on votetype 2
join comments
join favouites (multiply joins by number of rows)

那么什么会更好地扩展？我知道可以添加一些额外的字段来存储计数，因此不需要连接。但是两者都需要相同数量的连接，我无法下定决心。

Answer 1

我会比 2 更进一步。问题是，您的模型中的实体是什么？答：用户和帖子。帖子可以是问题、答案、投票、评论或其他任何内容，但它始终是帖子。因此

posts(id, postTypeId, userId, title, body)
postTypeId(id, postType)

顺便说一句，您提到的两个选择都会检索所有内容（或者它们只是为了显示最糟糕的连接？）。

我不会看到自己一次性获取他的问题和他的答案和他的cmets和......所有这些。哪个用例需要这样的一切？