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

Question

我正在使用两种模式，我无法确定哪种模式更具可扩展性。该模式适用于Q＆amp; A，它是在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)

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

我不会看到自己在和中回答和他的回答和他们的问题和 ......一气呵成。哪个用例需要这样的一切？