Jango's MutiTable Vs. Аннотация Наследование

Question

Хотя существует общее мнение о том, что наследование на несколько таблиц не является очень хорошей идеей в долгосрочной перспективе (Jacobian, Others), мне интересно, могут ли в некоторых случаях «дополнительные объединения», созданные django во время запросов, стоило того.

В моей базе данных имеется единственный источник правды. Скажем, для объектов Person, которые идентифицируются с использованием идентификационного номера и типа идентификации. Например. Идентификационный номер 222, Тип паспорта.

class Person(models.Model): 
    identity_number = models.CharField(max_length=20) 
    identity_type = models.IntegerField() 

class Student(Person): 
    student_number = models.CharField(max_length=20) 

class Employee(Person): 
    employee_number = models.CharField(max_length=20) 

В абстрактном наследовании любая модель подкласса человека, например. Студент, Родитель, руководитель, сотрудник и т.д. унаследовав от человека абстрактного класса будет иметь identity_number & identity_type хранятся в соответствующих таблицах

В наследованию за несколькими столами, так как все они имеют тот же стол, я могу быть уверен, что если я создаю уникальное ограничение на оба столбца в модели Person, а затем нет дубликатов будет существовать в базе данных.

В абстрактном наследовании, чтобы избежать дубликатов в базе данных, нужно было бы добавить дополнительную дополнительную логику проверки в приложение, что также привело бы к снижению производительности, означая, что он отменяет «дополнительное соединение», которое django имеет отношение к конкретному наследование?

Answer 1

Ошибочно думать о моделировании данных в объектно-ориентированных терминах. Это абстракция, которая плохо относится к реляционным базам данных, скрывая некоторые очень важные детали, которые могут существенно повлиять на производительность (как указано в статьях) или правильность (как вы указали выше).

Традиционный подход к SQL вашего примеру будет предлагать две возможности:

1. Имея Person таблицы с идентификаторами, а затем Student и т.д. с внешними ключами обратно к нему.
2. Имея единую таблицу для всего, с некоторыми дополнительными полями, чтобы отличать разные виды людей.

Теперь, если ваша оценка заставила вас предпочесть 1, вы можете заметить, что в Django это может быть достигнуто с использованием конкретной модели наследования (это то же, что и вы, описанные выше). В этом случае, во что бы то ни стало, используйте наследование, если вы обнаружите, что результирующие шаблоны доступа в Django более элегантны.

Так что я не говорю, что вы не должны использовать наследование, я говорю, что вы должны смотреть на него только после того, как вы смоделировали свои данные с точки зрения SQL. Если бы вы сделали это в приведенном выше примере, вы бы даже не подумали о том, чтобы расщепить все на отдельные таблицы, в которых есть все проблемы, которые вы заметили, - как это предлагает абстрактная модель наследования.