Rails 3.0 - лучшие практики: несколько подтипов модельного объекта

Question

Так что, возможно, на этот вопрос довольно легко ответить, но в любом случае здесь.

Я хочу иметь это представление, скажем media_objects /, которое показывает список медиа-объектов.Достаточно просто, правда?Однако я хочу, чтобы список объектов мультимедиа представлял собой набор вещей, которые, например, являются подтипами MediaObject, CDMediaObject, DVDMediaObject.Каждый из этих подтипов должен быть представлен таблицей БД для конкретного набора метаданных, который не является полностью общим для подтипов.

Моим первым шагом на этом пути было создание модели для каждого из подтипов, изменение MediaObject, чтобы он был достаточно умным, чтобы присоединиться к этим таблицам в отношении его концептуального поведения «все».Это кажется достаточно простым, но я в конечном итоге делаю много мелочей, которые кажутся не такими рельсами, поэтому я хотел бы попросить совета здесь.

У меня пока нет конкретного кода для этого примераОчевидно, но если у вас есть вопросы, я с удовольствием отредактирую этот вопрос, чтобы предоставить эту информацию ...

спасибо!

Answer 1

Создание модели для каждого подтипа - это путь, но вы говорите о наследовании нескольких таблиц. Rails предполагает наследование одной таблицы и обеспечивает действительно простую поддержку для его настройки. Добавьте столбец type в таблицу media_objects и добавьте все столбцы для каждого из определенных типов MediaObject в таблицу. Затем сделайте каждую из ваших моделей подклассом MediaObject:

class MediaObject < ActiveRecord::Base

end

class CDMediaObject < MediaObject

end

Rails будет обрабатывать извлечение записей и создание экземпляров правильного подкласса, так что когда вы MediaObject.find(:all), результаты будут содержать смесь экземпляров различных подклассов MediaObject.

Обратите внимание, что это не соответствует вашим требованиям:

Каждый из этих подтипов должен быть представлен таблицей БД для определенного набора метаданных, которые не являются общими для подтипов.

Rails - это соглашение о переконфигурации, и оно сделает вашу жизнь очень легкой, если вы напишете свое приложение на сильные стороны, а не ожидаете, что Rails адаптируется к вашим требованиям. Да, STI будет тратить пространство, оставляя некоторые столбцы незаполненными для каждой записи. Должны ли вы заботиться? Возможно нет; хранилище базы данных дешево, и дополнительные столбцы не повлияют на производительность поиска, если ваши важные столбцы имеют индексы.

Тем не менее, вы можете настроить что-то очень близкое к наследованию нескольких таблиц, но, вероятно, не следует.

Answer 2

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

В случае, если БД является postgres, я бы предложил использовать STI вдоль столбца hstore для хранения атрибутов, не общих для разных объектов. Это позволит избежать потери пространства в БД, но к атрибутам можно обращаться для различных операций.

Answer 3

Я бы сказал, это зависит от ваших данных: например, если различия между конкретными медиа-объектами не обязательно должны быть доступны для поиска, вы можете использовать одну таблицу БД со столбцом TEXT, скажем «Additional_attributes».С помощью rails вы могли бы затем сериализовать произвольные данные в этот столбец.

Если вы не можете пойти с этим, у вас может быть общая таблица "media_objects", которая "имеет один: набор данных".Затем в наборе данных вы можете сохранить специфику между CDMediaObject, DVDMediaObject и т. Д.

Совершенно другой подход будет заключаться в использовании MongoDB (вместо MySQL), который является хранилищем документов.Каждый документ может иметь совершенно другую форму.Все дерево документа также доступно для поиска.