Обзорная таблица для двух разных типов профилей в Django и БД PostgreSQL

У меня есть вопрос, как я должен спроектировать реляционную базу данных. У меня есть основной профиль, который имеет 2 подпрофиля, которые являются слабыми сущностями. Эти подпрофили представляют собой контрагенты бизнес-процесса, сотрудника и работодателя.

Учитывая, что я хочу иметь таблицы, связанные с этими подпрофилями, например "Review" или "Job Posting" (по аналогии с LinkedIn), какой подход будет наиболее подходящим:

  1. Создание отдельной таблицы для каждого типа профиля, например,
    EmployerReview и EmployeeReview
    2. .
  2. Создание единой унифицированной таблицы, поля которой определяют, какой тип подпрофиля отправляет и получает данные. например,

Review

  • отправитель models.ForeignKey(Profile...)
  • получатель models.ForeignKey(Profile...)
  • тип_отправителя models.CharField(max_length=15, choices=PROFILE_TYPES)
  • получатель_тип models.CharField(max_length=15, choices=PROFILE_TYPES)

Меня в первую очередь беспокоят проблемы с производительностью, например, когда нужно запросить все EmployerProfiles и связанные с ними Reviews этого профиля.
Если я правильно понял, то в методе 2. вам придется выполнять запрос с фильтром, что явно медленнее, чем select_related (аналогично SQL Join?).
Выигрыш будет заключаться в большей гибкости и простоте, но будет потеря производительности.
Какой из этих методов был бы более стандартизированным или оптимизированным способом для решения такой задачи?

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

" метод 2. ... который явно медленнее". Нет, это не так, где ваша демонстрация этого? Подумайте, для метода 1 вам нужен код, чтобы определить, к какой таблице обращаться. Этот код быстрее, чем фильтрация? Также может ли возникнуть условие, при котором необходимо использовать оба способа? Выполнение двух select (oj соединение таблиц) быстрее, чем фильтрация? Вы указали, что пробовали оба варианта, поэтому расширьте таблицы до 100 тыс. строк, а затем выполните каждый из них несколько раз в разной последовательности. Зафиксируйте EXPLAIN ANALYZE при каждом запуске. Также убедитесь, что вы фиксируете время выполнения кода приложения в дополнение к времени выполнения SQL.

Вернуться на верх