Одна полиморфная ассоциация против многих через / HABTM ассоциаций

Question

Я работаю над проектом, который в настоящее время имеет множество ассоциаций HABTM. По сути, все связано со всем остальным. Я рассматриваю возможность создания одной промежуточной таблицы / модели, которая имеет два полиморфных поля. Таким образом, если я добавлю другую модель, я могу легко подключить ее к остальным моделям. Это хорошая идея? Если нет, то почему? Если это так, то почему не все рельсовые проекты имеют такую ​​промежуточную таблицу?

Я вижу два других варианта. Я мог бы продолжать добавлять промежуточные таблицы или я мог бы добавить таблицу, которая содержит одну из каждого типа. Первый вариант - своего рода хлопот, а второй вариант не допускает самостоятельных соединений.

Answer 1

Несмотря на то, что полиморфная таблица соединений звучит так, как будто это упростит задачу, я думаю, вы в конечном итоге создадите для себя больше головной боли, чем она того стоит.Вот несколько потенциальных проблем / проблем вне моей головы:

1. Вы не сможете использовать has_and_belongs_to_many ассоциации ActiveRecord или связанных помощников без тонныхакинг / обезьяна, которая немедленно затмевает время, необходимое для настройки отдельных таблиц парных ссылок.

2. Ваша таблица соединения будет иметь два столбца id , назовем их a_id и b_id.Для любой данной пары моделей вы должны убедиться, что идентификаторы всегда будут в одном столбце.

   Пример: если у вас есть две модели с именами User и Role, вам необходимо убедиться, что для этой пары user_id всегда хранится в столбце a_id, а role_id всегдахранится в столбце b_id, в противном случае вы не сможете индексировать таблицу каким-либо значимым образом (и вы рискуете определить одно и то же отношение дважды).

3. ЕслиВы когда-нибудь захотите использовать принудительное применение ограничений ограничений FOREIGN KEY в базе данных. Маловероятно, что эта схема таблицы полиморфных ссылок будет поддерживаться.

4. Таблица универсальных ссылок увеличится в n раз чем отдельные таблицы ссылок.При хорошей индексации не должно иметь значения много , но по мере роста вашего приложения и данных это может стать головной болью и ограничить некоторые ваши возможности в отношении масштабирования.Дайте вашей БД перерыв.

5. Наиболее или менее важно (я не могу решить), вы будете нарушать норму, а это значит, что гораздо меньше (если таковые имеются) ресурсов, чтобы помочь вамкогда вы столкнетесь с неприятностями.В основном обоснование Адама Сэндлера "они все будут смеяться над тобой".

Последняя мысль: Можете ли вы удалить любую из таблиц ссылок, используя has_many :xxx, :through => :xxx взаимосвязи?

Answer 2

Я думаю, что было бы чище и гибче, если бы вы использовали несколько таблиц соединения, а не одну гигантскую многоцелевую таблицу соединения.

Answer 3

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