Проектирование базы данных и отношений при создании подкласса модели

Question

У меня есть модель "Задача", которая будет иметь много "TaskTargets".

Однако, когда дело доходит до TaskTargets, я пишу базовый класс TaskTarget, который является абстрактным (насколько это возможно в Rails). TaskTarget будет разделяться на различные концептуализации всего, что может быть целью задачи. Так сказать, программная подсистема, сайт клиента, ванная и т. Д. ...

Дизайн классов здесь довольно прост, но я сталкиваюсь с тем, как я буду связывать все это вместе и как у меня будут рельсы для управления этими отношениями.

Сначала я подумал, что у меня будет таблица TaskTarget, которая будет содержать основные общие поля (имя, описание ...). Затем он также будет иметь полиморфную связь с таблицей, специфичной для типа данных, которые реализует реализующий класс. Это означает, что данные для одного экземпляра класса, реализующего TaskTarget, будут найдены в двух таблицах.

Второй подход заключается в создании полиморфных отношений HABTM между Task и подклассами TaskTarget, которые, как я думал, я мог бы использовать повторно для имени таблицы TaskTarget для таблицы объединения.

Вариант № 2 Я подозреваю, что это самый надежный, но, возможно, я что-то упустил. Спасибо за любую помощь и, конечно же, я просто прошу убедиться, что я сделаю это правильно, один раз!

Answer 1

Я думаю, что два подхода (легко) доступные вам в Rails:

1) Наследование одной таблицы : вы создаете одну таблицу TaskTarget, в которой есть каждое поле, которое может захотеть каждый подкласс. Затем вы также добавляете поле «type», в котором хранится имя класса, а Rails сделает все остальное за вас. См. ActiveRecord api docs для получения дополнительной информации, особенно в разделе «Наследование отдельных таблиц».

2) Наследование бетонной таблицы : Нет таблицы для базового класса TaskTarget. Вместо этого просто создайте таблицу для каждого конкретного класса в вашей иерархии, используя только поля, необходимые для этого класса.

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

Второй вариант обеспечивает более чистую схему, которую несколько легче читать, и каждый класс будет работать почти так же, как любая обычная модель ActiveRecord. Однако объединение всех таблиц TaskTarget может быть громоздким, особенно если в будущем вы добавите больше подклассов. Реализация любых необходимых полиморфных ассоциаций может также включать некоторую дополнительную сложность.

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