Когда нужна денормализация в БД?

# Денормализация в базах данных

Денормализация — это процесс преднамеренного введения избыточности в структуру базы данных, нарушающий нормальные формы, чтобы улучшить производительность. Это противоположность нормализации и применяется при наличии конкретных проблем.

Когда денормализация необходима

1. Высокая нагрузка на чтение (READ-HEAVY системы)

Когда операции чтения значительно преобладают над записями:

# Денормализованный подход
class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    customer_id = Column(Integer, ForeignKey("customers.id"))
    # Кэшированные данные для избежания JOIN
    customer_name = Column(String)  # дублируем из customers.name
    total_price = Column(Float)     # предвычисленная сумма
    
# Нормализованный подход требовал бы:
# SELECT o.id, c.name, SUM(...) FROM orders o JOIN customers c ...
# При каждом запросе — дорого

2. Частые агрегирующие запросы

Когда постоянно вычисляются SUM, COUNT, AVG:

# Вместо SELECT COUNT(*) FROM comments WHERE post_id=?
# Хранишь denormalized_count в таблице posts
class Post(Base):
    __tablename__ = "posts"
    id = Column(Integer, primary_key=True)
    title = Column(String)
    comments_count = Column(Integer, default=0)  # обновляется триггером
    views_count = Column(Integer, default=0)
    total_likes = Column(Integer, default=0)

3. Поиск по вложенным данным

Когда нужен индекс по данным из related таблицы:

# Денормализация для поиска
class Comment(Base):
    __tablename__ = "comments"
    id = Column(Integer, primary_key=True)
    post_id = Column(Integer, ForeignKey("posts.id"))
    author_id = Column(Integer, ForeignKey("users.id"))
    # Денормализуем для быстрого поиска
    author_email = Column(String, index=True)  # вместо JOIN + index
    post_title = Column(String, index=True)

4. Аналитика и отчёты

Для витрин данных и аналитических запросов:

# Data Warehouse паттерн
class SalesMetrics(Base):
    __tablename__ = "sales_metrics_daily"
    date = Column(Date, primary_key=True)
    region = Column(String, primary_key=True)
    # Один запрос вместо сложного JOINа
    total_revenue = Column(Float)
    total_orders = Column(Integer)
    unique_customers = Column(Integer)
    avg_order_value = Column(Float)

5. Геодистрибьютированные системы

Когда данные реплицируются в разные регионы:

# Денормализация для синхронизации
class UserProfile(Base):
    __tablename__ = "user_profiles"
    user_id = Column(Integer, primary_key=True)
    # Кэшируем иммutable данные для распределённых запросов
    username = Column(String)
    email = Column(String)
    subscription_status = Column(String)  # вместо JOIN с users

Риски денормализации

Сложность обновлений:

# Нужна синхронизация в нескольких местах
def update_customer_name(customer_id, new_name):
    db.session.execute(
        update(Customer).where(Customer.id == customer_id)
        .values(name=new_name)
    )
    # Плюс обновление во всех заказах этого клиента
    db.session.execute(
        update(Order).where(Order.customer_id == customer_id)
        .values(customer_name=new_name)
    )
    db.session.commit()

Риск несогласованности данных:

• Используй триггеры или ORM для автоматической синхронизации
• Или асинхронные джобы для обновления денормализованных полей

Стратегия применения

1. Сначала нормализуй — начни с нормальной формы
2. Профилируй — найди узкие места (медленные запросы)
3. Измеряй — посчитай cost/benefit
4. Денормализуй локально — только проблемные места
5. Документируй — отметь синхронизацию

Альтернативы денормализации

• Кэширование (Redis, Memcached) — проще поддерживать
• Материализованные представления — денормализация на уровне БД
• CQRS — отдельные модели для чтения и записи
• Поиск (Elasticsearch) — для полнотекстового поиска

Денормализация — это инструмент, а не правило. Используй её когда измеренные данные показывают реальную проблему с производительностью, а не профилактически.