Наследование одной таблицы

Это хорошая идея ? По-разному. Это нарушает нормализацию, поскольку таблица не имеет единственной цели. Что произойдет, если вы расширите базовый класс в энный раз? Вам нужно будет добавить столбцы в таблицу. У большинства современных БД нет проблем с этим, поскольку вы можете изменить таблицу, но как насчет рефакторинга и удаления класса. Теперь у вас есть столбцы, у которых нет цели.

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

Я не знаю об эффектах Rails.

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

Например, у меня есть приложение, в котором каждый из моих продуктов содержит одну или несколько комиссий, каждая из которых рассчитывается немного по-разному. В моей объектной модели я хочу иметь подклассы класса Fee, каждый из которых умеет вычислять себя. Я действительно не хочу иметь таблицу для каждого типа комиссии: поэтому я создаю Fee как базовый класс и сборы как таблицу, которая содержит объединение всех полей, необходимых для всех подтипов, плюс «тип» столбец, значение которого соответствует названию соответствующего подкласса. После этого ActiveRecord займется сантехникой.

Короче говоря, наследование одной таблицы (STI) - это шаблон проектирования, который позволяет отображать отношения наследования ООП с базой данных. Если вы определяете какие-либо подклассы из объектов модели ActiveRecord, вам следует рассмотреть STI.

STI (изначально?) Задокументирована в книге Мартина Фаулера «Шаблоны архитектуры корпоративных приложений», а также описана в канонической книге DHH «Гибкая веб-разработка с Rails» (раздел 18.4, я думаю). Я отсылаю вас к этим книгам, потому что они дают гораздо лучшее объяснение, чем я мог бы надеяться сделать в этой области.

Я категорически не согласен с мнением, выраженным на сайте www.matthewpaulmoore.com (ссылка на который содержится в этой ветке robintw), что ИППП по своей сути - это плохо. Это кажется несколько наивным взглядом, который не учитывает использование наследования ООП. Я использовал STI для создания некоторых элегантных решений в Rails, но я полагаю, что вы можете злоупотреблять любым шаблоном проектирования.

Окончательная ссылка. Это позволяет в одной таблице хранить несколько объектов, имеющих общий базовый класс.

Ruby on Rails использует библиотеку под названием Active Record. Это обычная среда Ruby, поддерживающая STI.

Я могу говорить только с точки зрения (новой) ADO Entity Framework, которая включает функциональность таблицы для каждого типа (TPT).

Вот хорошая серия сообщения в блоге, знакомящие с основными концепциями (с использованием Entity Framework), также есть статья MSDN по этому поводу здесь.

Также, похоже, есть некоторые рекомендации по использованию nHibernate для TPT, они находятся здесь.

Вот эта ссылка, которая объясняет наследование типов таблиц в SQL Server.. Кажется, это довольно хорошее резюме и введение в концепцию.

Я не уверен, какое влияние это окажет на Rails.

Я только что видел http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti, что говорит о плохой идее.

В целом я считаю это полезным, но я обнаружил несколько ошибок

Пример в этой ссылке может дать полезную картину того, как вы можете его использовать.