Лучше ли объединять подклассы модели и иметь неиспользуемые поля или создавать конкретные подклассы?

#django #inheritance #django-models #orm

#django #наследование #django-модели #orm

Вопрос:

Я пишу приложение на Django, и у меня есть экземпляр, в котором я хотел бы создать модель с одним уровнем наследования для нескольких подклассов. то есть:

Транспортные средства -> Автомобили, велосипеды, автобусы

Мне нужно иметь возможность искать и хранить элементы как суперкласс Vehicle, но в большинстве случаев пониженный до подкласса, чтобы использовать дополнительные поля. В Django это вызовет множество обращений к базе данных для извлечения подмоделей или массивное объединение и запрос.

Должен ли я использовать конкретные подклассы и снизить производительность, или мне следует добавить дополнительные поля к одной модели транспортного средства, а затем иметь неиспользуемые поля в различных объектах?

Я должен отметить, что дополнительные поля обычно представляют собой 1-3 поля небольшого размера, т. Е. строки символов, и что всего 4 подкласса (максимум 9 неиспользуемых полей на модель)

Ответ №1:

Основной ответ на этот вопрос таков — везде, где вы можете вызвать ‘JOIN’ в схеме базы данных SQL, вы должны избегать этого.

Причина этого в том, что сложность команды JOIN самая высокая и занимает больше всего времени. Итак, в целом, рекомендация заключается в следующем:

  1. Если связь является OneToOne, и вы знаете, что эта связь никогда не станет OTM (OneToMany), то поместите все в одну таблицу.
  2. Если связь является OTO, но содержит контент с высоким риском (например, хэши паролей и т.д.), Вам следует избегать размещения его в одной таблице по соображениям безопасности.
  3. Если связь OTM или MTM , у вас действительно нет другого выбора, кроме как разделить ее.

Комментарии:

1. Это избранный случай, когда отношение является OTM, но с оговоркой, что его небольшое количество (many) и это позволит избежать объединений в том, что станет огромными таблицами.

2. Я думаю, что я буду использовать один суперкласс и дамп дополнительных полей в поле JSON с помощью базы данных postgres, я все еще могу запрашивать это без особой потери производительности, и это не займет места с неиспользуемыми полями.

3. Да, поле JSON иногда является хорошим решением, если вы используете postgres DB — преимущества SQL в сочетании с преимуществами NoSQL 🙂