Стоит ли каким-либо образом избегать многотабличного (конкретного) наследования в Django?

Прежде всего, наследование не имеет естественного преобразования в архитектуру реляционной базы данных (хорошо, я знаю, объекты Oracle Type и некоторые другие СУБД поддерживают наследование, но django не использует эту функциональность)

На этом этапе обратите внимание, что django генерирует новые таблицы для подклассов и записывает много left joins для извлечения данных из этих "подтаблиц". И левые присоединения не являются вашими друзьями. В сценариях с высокой производительностью, таких как серверная часть игры или что-то еще, вы должны избегать этого и разрешать наследование «вручную» с некоторыми артефактами, такими как нули, OneToOne или внешние ключи. В OneToOne сценарии вы можете вызвать связанную таблицу напрямую или только при необходимости.

... НО ...

На мой взгляд (TGW) вам следует включить наследование модели в свои корпоративные проекты, когда оно попадает в ваш дискурсивная вселенная. Я делаю это и благодаря этой функции экономлю много времени для своих клиентов. Кроме того, код становится чистым и элегантным, что означает простоту обслуживания (обратите внимание, что у таких проектов нет сотен запросов или запросов в секунду).

Вопрос за вопросом

В: Что не так с таким наследованием в Django?
A: Много таблиц, много левых соединений.

Вопрос: Почему явные OneToOneFields лучше?
A: Вы можете получить прямой доступ к связанной модели без левых соединений.

Q: Есть ли наглядные примеры (тесты)?
A: Нет сопоставимых.

В: Разве select_related () не позволяет нам контролировать, когда вызываются JOIN?
A: django объединяет необходимые таблицы.

В: Каковы альтернативы многотабличному наследованию, когда мне нужно ссылаться на базовый класс в другой модели?
A: Аннулирование. Отношения OneToOne и множество строк кода. Это зависит от потребностей приложения.

Q: GenericForeignKeys лучше в этом случае?
A: Не для меня.

Вопрос: Что делать, если мне требуется OneToOneField для базовой модели?
A: Напишите это. С этим проблем нет. Например, вы можете расширить модель User, а также у вас может быть базовая модель OneToOne to User для некоторых пользователей.

Заключение

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

Шутка: можно написать на ассемблерном коде, и он будет работать быстрее.

Насколько я понимаю, вы используете OneToOneField на RelatedModel BaseModel, потому что в конечном итоге вам нужна прямая связь между RelatedModel и каждым Submodel1 на Submodel9. Если это так, существует более эффективный способ сделать это без наследования нескольких таблиц и общих отношений.

Просто избавьтесь от BaseModel и в каждом SubmodelX поставьте от OneToOneField до RelatedModel

class Submodel1(models.Model):
    related_model = models.OneToOneField(RelatedModel, null=True, blank=True, related_name='the_thing')
    some_field = models.TextField()

# ...

class Submodel9(models.Model):
    related_model = models.OneToOneField(RelatedModel, null=True, blank=True, related_name='the_thing')
    another_field = models.TextField()

Это позволит вам получить доступ к SubmodelX из экземпляра RelatedModel, используя поле с именем the_thing, как в первом примере наследования нескольких таблиц.

Обратите внимание, что вы можете использовать абстрактное наследование, чтобы исключить поле related_model и любые другие общие поля от SubModel1 до Submodel9.

Причина, по которой использование наследования нескольких таблиц неэффективно, заключается в том, что оно создает дополнительную таблицу для базовой модели и, следовательно, дополнительные JOINs для доступа к этим полям. Использование общих отношений будет более эффективным, если позже вы обнаружите, что вместо этого вам нужно поле ForeignKey от RelatedModel до каждого SubmodelX. Однако Django не поддерживает общие отношения в select_related(), и вам, возможно, придется создавать собственные запросы, чтобы сделать это эффективно. Выбор между производительностью и простотой кодирования зависит от вас, в зависимости от того, какую нагрузку вы ожидаете на сервере и сколько времени вы хотите потратить на оптимизацию.

Мир изменился.

Прежде всего следует отметить, что статье под названием Django gotcha: конкретное наследование было почти четыре года. в то время, когда был задан этот вопрос; в 2014 году. С тех пор как Django, так и RDBM-системы прошли долгий путь (например, mysql 5.0 или 5.1 были широко используемыми версиями, а до общего выпуска 5.5 оставался еще один месяц).

Присоединяется слева от меня, присоединяется справа от меня

Это правда, что наследование нескольких таблиц действительно приводит к дополнительным объединениям за кулисами большую часть времени. Но присоединения - это не зло. Стоит отметить, что в правильно нормализованной базе данных вам почти всегда нужно присоединиться, чтобы получить все необходимые данные. Когда используются правильные индексы, объединения не включают каких-либо значительных потерь производительности.

ВНУТРЕННЕЕ СОЕДИНЕНИЕ против ЛЕВОГО ВНЕШНЕГО СОЕДИНЕНИЯ

Это действительно относится к наследованию нескольких таблиц, с помощью других подходов можно избежать дорогостоящего LEFT OUTER JOIN и вместо этого выполнить INNER JOIN или, возможно, подзапрос. Но с наследованием нескольких таблиц вам отказывают в таком выборе

Я не могу сказать, является ли появление LEFT OUTER JOIN проблемой само по себе, но, в любом случае, может быть интересно отметить, в каких случаях эти внешние соединения действительно происходят.

Это наивная попытка проиллюстрировать вышесказанное на некоторых примерах запросов.

Предположим, у нас есть несколько моделей, использующих многотабличное наследование:

from django.db import models

class Parent(models.Model):
    parent_field = models.CharField(max_length=10)


class ChildOne(Parent):
    child_one_field = models.CharField(max_length=10)


class ChildTwo(Parent):
    child_two_field = models.CharField(max_length=10)

По умолчанию дочерние экземпляры получают parent_ptr, а родительские экземпляры могут обращаться к дочерним объектам (если они существуют) с помощью childone или childtwo. Обратите внимание, что parent_ptr представляет собой взаимно-однозначное отношение, которое используется в качестве первичного ключа (фактические дочерние таблицы не имеют столбца id).

Вот быстрый и грязный модульный тест с некоторыми наивными примерами Django запросов, показывающий соответствующее количество вхождений INNER JOIN и OUTER JOIN в SQL:

import re
from django.test import TestCase
from inheritance.models import (Parent, ChildOne, ChildTwo)

def count_joins(query, inner_outer):
    """ Count the occurrences of JOIN in the query """
    return len(re.findall('{} join'.format(inner_outer), str(query).lower()))


class TestMultiTableInheritance(TestCase):
    def test_queries(self):
        # get children (with parent info)
        query = ChildOne.objects.all().query
        self.assertEqual(1, count_joins(query, 'inner'))
        self.assertEqual(0, count_joins(query, 'outer'))
        # get parents
        query = Parent.objects.all().query
        self.assertEqual(0, count_joins(query, 'inner'))
        self.assertEqual(0, count_joins(query, 'outer'))
        # filter children by parent field
        query = ChildOne.objects.filter(parent_field=parent_value).query
        self.assertEqual(1, count_joins(query, 'inner'))
        self.assertEqual(0, count_joins(query, 'outer'))
        # filter parents by child field
        query = Parent.objects.filter(childone__child_one_field=child_value).query
        self.assertEqual(1, count_joins(query, 'inner'))
        self.assertEqual(0, count_joins(query, 'outer'))
        # get child field values via parent
        query = Parent.objects.values_list('childone__child_one_field').query
        self.assertEqual(0, count_joins(query, 'inner'))
        self.assertEqual(1, count_joins(query, 'outer'))
        # get multiple child field values via parent
        query = Parent.objects.values_list('childone__child_one_field',
                                           'childtwo__child_two_field').query
        self.assertEqual(0, count_joins(query, 'inner'))
        self.assertEqual(2, count_joins(query, 'outer'))
        # get child-two field value from child-one, through parent
        query = ChildOne.objects.values_list('parent_ptr__childtwo__child_two_field').query
        self.assertEqual(1, count_joins(query, 'inner'))
        self.assertEqual(1, count_joins(query, 'outer'))
        # get parent field value from parent, but through child
        query = Parent.objects.values_list('childone__parent_field').query
        self.assertEqual(0, count_joins(query, 'inner'))
        self.assertEqual(2, count_joins(query, 'outer'))
        # filter parents by parent field, but through child
        query = Parent.objects.filter(childone__parent_field=parent_value).query
        self.assertEqual(2, count_joins(query, 'inner'))
        self.assertEqual(0, count_joins(query, 'outer'))

Обратите внимание, что не все эти запросы имеют смысл: они предназначены только для иллюстративных целей.

Также обратите внимание, что этот тестовый код не является СУХИМ, но это сделано специально.

Django реализует многотабличное наследование через автоматически созданный OneToOneField, как говорится в его документации. Поэтому либо используйте абстрактное наследование, либо я не думаю, что использование явного OneToOneFields или ForeignKeys имеет какие-либо различия.