Какая из этих двух схем более масштабируема? - PullRequest
Новая
       0

Какая из этих двух схем более масштабируема?

0 голосов
/ 30 ноября 2010

Я играю с двумя схемами и не могу решить, какая из них более масштабируема.Схема предназначена для вопросов и ответов, и она встроена в 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)

Так что будет лучше масштабироваться?Я знаю, может добавить некоторые дополнительные поля для хранения счетчиков, поэтому не требуется никаких объединений.Но оба требуют одинакового количества соединений, и я не могу принять решение.

1 Ответ

1 голос
/ 30 ноября 2010

Я бы пошел даже дальше, чем 2. Вопрос в том, какие сущности в вашей модели?Ответ: пользователи и посты.Пост может быть вопросом, ответом, голосованием, комментарием или чем-то еще, но это всегда пост.Таким образом, 

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

Кстати, оба упомянутых вами выбора извлекают все (или они просто показывают худшее из возможных объединений?).

Я бы не сталвижу, как я беру его вопросы и его ответы и его комментарии и ... все за один раз.Какой вариант использования потребует всего этого?

...