Жесткая база данных наследования / проектное решение модели

Question

У меня есть Users, который может быть либо TypeS, TypeC, либо TypeA. У меня есть модели для каждого из этих типов, чтобы хранить дополнительную информацию. Теперь, в таблице Users, я должен иметь

1. 3 пустых поля внешнего ключа для обозначения, какого типа они являются
2. 2 поля, 1 с именем типа и 1 с внешним ключом
3. 1 поле, обозначающее тип с внешним ключом на другой модели
4. нет поля для пользователя, и полагаться на проверку обратной связи?

Я использую Django, если вы хотите дать более точный ответ.

Answer 1

Django предоставляет Родовые отношения как часть фреймворка типов контента , что позволяет вам реализовать нечто подобное вашему варианту №2, просто более гибкое. Вы можете установить общие отношения, добавив в вашу модель следующие поля:

content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')

Таким образом, вы можете назначить один из TypeS, TypeC или TypeA каждому рассматриваемому пользователю. Кроме того, если вам когда-нибудь понадобится добавить TypeX или TypeY, вы уже настроены и вам не нужно расширять модель.

Answer 2

Я бы использовал опцию №1, 3 внешних ключа, допускающих обнуление. Это позволяет вам использовать фактические связи с внешними ключами базы данных, что не подходит вариантам № 2, № 3 и № 4. Из-за этого вы получите:

• самый простой и быстрый поиск дополнительной информации
• Неиспользуемое дисковое пространство минимально
• Логика программирования для определения того, какой тип не является сложным (хотя и немного более сложным, чем если бы у вас была возможность «двух полей»).

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

РЕДАКТИРОВАТЬ: Есть одна причина, чтобы рассмотреть вариант № 2 ... если вы ожидаете, что возможно, что число типов может увеличиться с 3 до 10 или 100, система вариант № 1 будет становиться все более раздражающим.

Answer 3

Я сталкивался с этой ситуацией пару раз сам. Мое личное предпочтение - вариант 1 (если не будет 20 типов пользователей).

• Опция 1 дает вам возможность делать ссылки на внешние ключи для обеспечения целостности базы данных (с ограничением на три столбца).

• Вариант 2 - это не фактическая ссылка на внешний ключ. Запись больше не может существовать в таблице типов. Объединения таблиц исключены.

• Вариант 3 даже хуже, чем вариант 2, значение необходимо интерпретировать перед переходом к таблице типов.

• Вариант 4 возможен, но это немного похоже на поиск ваших типов данных. Это позволило бы одному пользователю иметь несколько определений типов.