Вопрос

Ответ на мой вопрос по дизайну БД предложил так называемое наследование одной таблицы.Я немного поискал по этому поводу, но, похоже, не нашел столько четкой информации по этому поводу.

По сути, я, кажется, понимаю, что у вас есть большая таблица со всеми полями в ней, а также поле типа, а затем ваш уровень ORM использует поле типа, чтобы предоставить вам различные представления объектов.Это верно?

Что еще более важно, является ли наследование одной таблицы «одобренным» методом проектирования базы данных?Под этим я подразумеваю, «разумно» ли его использовать?Безопасно ли его использовать или это вызывает проблемы?

Другой вопрос: насколько хорошо это работает в рельсах?Я нашел несколько ссылок на него в Rails - но вызывает ли это проблемы, если делать что-то нетрадиционным способом?

Любая помощь очень ценится.

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

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

Ruby on Rails использует библиотеку под названием Активная запись.Это обычная среда 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 что говорит о том, что это плохая идея.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top