Законно ли это использование наследования одной таблицы в Rails?

Question

Я только что прочитал сообщение в блоге Чада Фаулера о 20 разработок Rails, которые запрещены.По поводу наследования одной таблицы он комментирует:

Хранение столбца с именем «type», содержащего имя класса, является довольно хорошим индикатором того, что происходит что-то подозрительное.Это подозрительно, но не всегда плохо.Однако я думаю, что каждый раз, когда вы его используете, вам следует не раз спросить себя, правильное ли это решение.Базы данных не делают того, что они делают лучше всего, когда у вас много ИППП и полиморфных ассоциаций.

Я пишу приложение для блога и рассматриваю возможность использования STI для комментариев, которые можно оставлять к сообщению, и для контактных сообщений, которые посетители могут публиковать, если хотят связаться со мной.Мой Message модель унаследует от моей Comment модель.Они оба имеют общие атрибуты, за исключением того, что Message будет иметь дополнительный subject поле.Еще одна общая черта заключается в том, что оба сообщения будут отправлены в Akismet для проверки на спам.

Вместо того, чтобы просто несколько раз спрашивать себя, является ли это правильным решением, как предлагает Чад, я подумал, что получу мнение и от экспертов Stack Overflow!Подходит ли то, что я предлагаю, для ИППП?

Answer 1

Я использовал STI несколько раз.Рассмотрим CMS, которая может иметь Page, NewsItem, BlogItem и т. д.

Каждый из них может происходить от общего класса, который, в свою очередь, наследуется от ActiveRecord.Таблица для каждой из них будет одинаковой (заголовок, тело, теги, опубликованный_at), но каждая модель может иметь разные ассоциации, разные статусы или другой рабочий процесс, поэтому каждая модель имеет собственный код в своем собственном классе.Однако все они имеют общую таблицу и родительский класс.Это также позволяет мне использовать родительский класс для поиска между классами и автоматически набирать результирующий массив записей.

Существуют и другие способы решения этой проблемы, и, возможно, это не лучший пример, но, безусловно, бывают случаи, когда STI удобен в ситуациях, когда поведение объекта может отличаться, но сохраняемое состояние остается тем же.Конечно, вы должны быть уверены, что так будет и в будущем.

В вашем случае комментарии и контактные сообщения разные.Похоже, нет никакой пользы от их размещения в одной таблице.Возможно, поместите общий код в родительский класс или, еще лучше, в модуль в /lib.