Удобно ли использовать наследование Django ORM при создании БД

Удобно ли использовать наследование Django ORM при создании БД

Наследование в Django ORM — это мощная, но сложная функция. Её удобство зависит от сценария использования. Давайте разберёмся в трёх типах наследования и когда их использовать.

Три типа наследования в Django ORM

1. Abstract Base Classes (рекомендуется)

Абстрактный базовый класс — это класс, который НЕ создаёт таблицу в БД, а просто предоставляет поля для наследников.

from django.db import models

# Абстрактный базовый класс
class TimeStampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    
    class Meta:
        abstract = True  # Это важно!

# Наследники — создают свои таблицы
class User(TimeStampedModel):
    name = models.CharField(max_length=100)
    email = models.EmailField()

class Post(TimeStampedModel):
    title = models.CharField(max_length=200)
    content = models.TextField()
    author = models.ForeignKey(User, on_delete=models.CASCADE)

# В БД:
# auth_user: id, name, email, created_at, updated_at
# auth_post: id, title, content, author_id, created_at, updated_at

Преимущества Abstract:

• Очень удобно для переиспользования полей (created_at, updated_at, is_active)
• Нет дополнительных таблиц в БД
• Нет JOIN при запросах
• Чистая и простая схема БД

Недостатки:

• Нельзя создавать экземпляры абстрактного класса
• Нельзя запрашивать только объекты TimeStampedModel

2. Multi-table Inheritance (сложно, не рекомендуется)

Каждый класс создаёт свою таблицу. Наследники связаны с родителем через автоматический ForeignKey.

class Vehicle(models.Model):
    make = models.CharField(max_length=100)
    model = models.CharField(max_length=100)
    year = models.IntegerField()

class Car(Vehicle):
    num_doors = models.IntegerField()
    is_convertible = models.BooleanField()

class Truck(Vehicle):
    cargo_capacity = models.IntegerField()

# В БД создаются ТРИ таблицы:
# vehicles: id, make, model, year
# car: vehicle_ptr_id (FK), num_doors, is_convertible
# truck: vehicle_ptr_id (FK), cargo_capacity

Преимущества Multi-table:

• Каждый класс имеет свою таблицу
• Полиморфизм: можно работать с Vehicle, Car, Truck отдельно
• Тип объекта явно записан в БД

Недостатки (серьёзные!):

• МНОГО JOIN при запросах (плохая производительность)
• Сложность в миграциях
• Трудно удалять родительский объект
• Запросы медленнее чем обычные
• Усложняет схему БД

# Запрос к car с multi-table наследованием
car = Car.objects.get(pk=1)
# SELECT * FROM car JOIN vehicle ON car.vehicle_ptr_id = vehicle.id WHERE car.vehicle_ptr_id = 1
# ❌ Два JOIN вместо одного SELECT

3. Proxy Models (удобно, специализированный)

Прокси модель — это модель, которая имеет то же набор полей, что и родитель, но может иметь другой менеджер или методы.

class User(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField()
    is_staff = models.BooleanField(default=False)

# Прокси модель — одна таблица, другой интерфейс
class Staff(User):
    class Meta:
        proxy = True
        ordering = ['name']
    
    objects = StaffManager()  # Кастомный менеджер
    
    def get_permissions(self):
        return self.groups.all()

# В БД одна таблица: auth_user
# Но есть разные интерфейсы:
user = User.objects.get(pk=1)          # Обычный пользователь
staff = Staff.objects.get(pk=1)        # Тот же объект, другой интерфейс
print(user is staff)  # False, но это один и тот же объект БД

Преимущества Proxy:

• Нет дополнительных таблиц
• Нет JOIN
• Можно иметь разные менеджеры и методы
• Полезно для разных представлений одних данных

Недостатки:

• Нельзя добавлять новые поля
• Ограниченная гибкость

Рекомендации по использованию

ИСПОЛЬЗУЙ Abstract Base Classes для:

# 1. Переиспользуемых полей
class TimestampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    
    class Meta:
        abstract = True

# 2. Общих методов
class AuditedModel(models.Model):
    created_by = models.ForeignKey(User, on_delete=models.SET_NULL, null=True)
    created_at = models.DateTimeField(auto_now_add=True)
    
    class Meta:
        abstract = True
    
    def is_owner(self, user):
        return self.created_by == user

# 3. Soft delete поведения
class SoftDeleteModel(models.Model):
    deleted_at = models.DateTimeField(null=True, blank=True)
    
    class Meta:
        abstract = True
    
    def delete(self):
        self.deleted_at = now()
        self.save()
    
    @classmethod
    def objects(cls):
        return cls._default_manager.filter(deleted_at__isnull=True)

ИЗБЕГАЙ Multi-table Inheritance:

# ❌ ПЛОХО
class Vehicle(models.Model):
    make = models.CharField(max_length=100)

class Car(Vehicle):  # Multi-table наследование
    num_doors = models.IntegerField()

# ✅ ХОРОШО: использовать composition (композицию)
class Vehicle(models.Model):
    make = models.CharField(max_length=100)
    vehicle_type = models.CharField(
        max_length=20,
        choices=[("car", "Car"), ("truck", "Truck")]
    )

class CarDetails(models.Model):
    vehicle = models.OneToOneField(Vehicle, on_delete=models.CASCADE)
    num_doors = models.IntegerField()

ИСПОЛЬЗУЙ Proxy Models для:

# Разные представления данных
class User(models.Model):
    name = models.CharField(max_length=100)
    is_staff = models.BooleanField(default=False)

class AdminUser(User):
    class Meta:
        proxy = True
    
    objects = AdminManager()  # Только staff пользователи
    
    def get_dashboard(self):
        return self.get_admin_dashboard()

# Разные менеджеры для фильтрации
class ActiveUser(User):
    class Meta:
        proxy = True
    
    objects = ActiveUserManager()  # Только активные

Практический пример: Правильная структура

from django.db import models
from django.utils.timezone import now

# 1. Абстрактный базовый класс для общих полей
class TimeStampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    
    class Meta:
        abstract = True

# 2. Абстрактный класс для аудита
class AuditedModel(TimeStampedModel):
    created_by = models.ForeignKey(
        'auth.User',
        on_delete=models.SET_NULL,
        null=True
    )
    
    class Meta:
        abstract = True

# 3. Конкретные модели
class Post(AuditedModel):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published = models.BooleanField(default=False)
    
    def publish(self):
        self.published = True
        self.save()

class Comment(AuditedModel):
    post = models.ForeignKey(Post, on_delete=models.CASCADE)
    text = models.TextField()
    
    class Meta:
        ordering = ['created_at']

# 4. Прокси модель для разных представлений
class PublishedPost(Post):
    class Meta:
        proxy = True
        ordering = ['-created_at']
    
    objects = Post.objects.filter(published=True)

Производительность

# Multi-table наследование — МЕДЛЕННЕЕ
car = Car.objects.get(pk=1)
# SELECT * FROM car JOIN vehicle ON ...

# Abstract наследование — БЫСТРЕЕ
post = Post.objects.get(pk=1)
# SELECT * FROM post WHERE id = 1
# created_at и updated_at просто поля в таблице

Миграции

# Abstract модели упрощают миграции
# Когда добавляешь поле в абстрактный класс, миграция создаётся для всех наследников

class TimeStampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    # Добавить новое поле
    is_deleted = models.BooleanField(default=False)  # Миграция автоматически
    
    class Meta:
        abstract = True

Вывод

Итоговые рекомендации:

1. Используй Abstract Base Classes — это 90% случаев. Удобно, быстро, понятно в БД

   • Для общих полей (created_at, updated_at)
   • Для общих методов
   • Для переиспользуемого поведения

2. Избегай Multi-table Inheritance — сложность без пользы

   • Плохая производительность (много JOIN)
   • Трудные миграции
   • Запутанная схема БД

3. Используй Proxy Models — для разных интерфейсов к одним данным

   • Разные менеджеры
   • Разные методы
   • Одна таблица в БД

4. Предпочитай Composition (композицию) — когда нужна гибкость

   • Один класс — одна таблица
   • Связи через ForeignKey
   • Проще для понимания и поддержки

На 2026 год при работе с Django ORM абстрактные базовые классы — это стандарт де-факто. Multi-table наследование считается анти-паттерном в большинстве production кодов.