Что хотят услышать интервьюеры:

Ожидают услышать, что при проектировании базы данных учитывались целостность данных, нормализация, понятные связи между сущностями и реальные сценарии нагрузки. Важно показать, что схема строилась не “по учебнику”, а под требования продукта: быстрые чтения, допустимая стоимость записей, удобство поддержки. Хорошо, если упомянуть индексы, ограничения, транзакции и осознанные компромиссы между нормализацией и производительностью.

Определение:

При проектировании базы данных обычно опираются на несколько базовых принципов: хранить данные без лишнего дублирования, обеспечивать их консистентность, задавать четкие связи между таблицами и заранее думать о том, как данные будут читаться и изменяться.

На практике это означает:

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

Пример использования:

Например, в проекте интернет-магазина можно выделить таблицы users, orders, order_items, products.
У пользователя может быть много заказов, у заказа — много позиций, а у позиции заказа — ссылка на товар. Для часто используемых фильтров, например по user_id и дате заказа, добавляют индексы. Если список товаров в заказе нужен для быстрого отображения, можно хранить агрегированные данные отдельно, но только если это оправдано нагрузкой.

# Пример упрощенной структуры в ORM-стиле
class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    email = Column(String, unique=True, nullable=False)

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    user_id = Column(ForeignKey("users.id"), nullable=False)
    created_at = Column(DateTime, nullable=False)

class OrderItem(Base):
    __tablename__ = "order_items"
    id = Column(Integer, primary_key=True)
    order_id = Column(ForeignKey("orders.id"), nullable=False)
    product_id = Column(ForeignKey("products.id"), nullable=False)
    quantity = Column(Integer, nullable=False)

Пояснение кода:

Код показывает типичную схему с тремя связанными сущностями.

User хранит данные пользователя и имеет уникальный email, чтобы не допустить дубликаты.
Order ссылается на пользователя через user_id, что задает связь “один ко многим”.
OrderItem связывает заказ и товар, потому что один заказ содержит несколько позиций.

Такой подход помогает:

не дублировать данные пользователя в каждом заказе;
хранить заказ отдельно от его состава;
удобно строить запросы по заказам конкретного пользователя;
поддерживать целостность через внешние ключи.

Ключевые моменты:

Нормализация нужна, чтобы уменьшить дублирование и снизить риск несогласованных данных.
Связи между таблицами должны отражать реальные бизнес-связи: один-ко-многим, многие-ко-многим и т.д.
Ограничения NOT NULL, UNIQUE, FOREIGN KEY помогают поддерживать целостность.
Индексы добавляют под реальные запросы, а не “на всякий случай”.
Иногда полезна денормализация, если чтение критичнее записи и это подтверждено нагрузкой.
Хорошая схема — это баланс между корректностью, скоростью и простотой поддержки.

Какие основные принципы использовали при проектировании базы данных в вашем проекте?