Как решить сложность наследования одной таблицы в рельсах?

В настоящее время я рефакторинг моего приложения rails. Самая сложная часть — это таблица posts.

В текущей версии я использую posts для:

  • вопросы
  • ответы
  • Комментарии

Использование атрибута post_type.

Отношения:

  • Вопросы имеют много ответов и комментариев.
  • Ответы имеют много комментариев.
  • Ответ принадлежит вопросу.
  • Комментарий относится либо к ответу, либо к вопросу.

До сих пор я разделял типы сообщений вопросов и ответов на отдельные модели, используя одну и ту же таблицу: posts. Но с комментариями у меня следующая проблема:

Каждое сообщение, кроме комментариев, можно комментировать. Будет ли хорошей идеей создать дополнительную таблицу comments и создать полиморфную ассоциацию, «комментируемую» для каждого из типов сообщений, вместо того, чтобы наследовать таблицу сообщений?


ruby-on-rails database-design rails-models
person sn3ek    schedule 22.07.2013    source источник
comment
Я думаю, что имеет смысл вытащить их в «комментируемые», поскольку, если вы этого не сделаете, вы будете «комментировать» как в таблице вопросов, так и в таблице ответов (или вы будете присоединяться к таблице сообщений для комментариев ответов». просто кажется чище. это предполагает, что комментарий к вопросу и комментарий к ответу имеют одинаковые поля/требования   -  person Doon    schedule 22.07.2013
comment
Да, структура комментариев одинакова для всех типов сообщений. Я также думаю о разделении всей таблицы сообщений на вопросы и ответы для облегчения обслуживания.   -  person sn3ek    schedule 22.07.2013

Ответы (1)


arrow_upward
1
arrow_downward

Затем я начал читать ваш вопрос. Первое, что я подумал, это сначала разделить модели (как неразрушаемое или менее разрушаемое изменение), а затем на втором этапе разделить таблицы БД.

Что касается комментариев, я думаю, что у вас должна быть модель Comment, полиморфно связанная с Answer и Question.

Итак, на первом этапе вы должны разделить текущую модель Post на: Question, Answer и Comment, но продолжать использовать таблицу базы данных сообщений (поэтому я предполагаю, что default_scope в каждой из этих моделей устанавливает правильное значение post_type)

Вторым шагом будет (после первого тестирования, повторного тестирования и, возможно, даже развертывания для краш-теста) перенос данных для каждой модели в отдельную таблицу базы данных. Это упростит дизайн приложения, уменьшит количество данных в одной таблице и т. д. Это даже не должно иметь негативного влияния на производительность, поскольку количество запросов sql не изменится.

person Mike Szyndel    schedule 22.07.2013
comment
Спасибо. Я думаю, это то, что я буду делать. Я смотрел RailsCasts для STI и полиморфизма и решил удалить STI для лучшего обслуживания. - person sn3ek; 23.07.2013