Ответ вслух Middle Проектирование и нормализация спрашивают часто обновлено

Схема заказов интернет-магазина

Вопрос

Спроектируй схему базы для заказов интернет-магазина: клиенты, товары, заказы, оплаты. Какие таблицы, ключи и ограничения?

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

Базовые сущности: customers, products, orders, orderitems, payments. Заказ ссылается на клиента, позиции на заказ и товар, первичный ключ позиции (orderid, productid) или свой id, если один товар может быть в заказе дважды с разными опциями.

Что должно прозвучать в ответе

  • Таблицы customers, products, orders, order_items, payments и их связи

  • order_items как связь заказа и товара с qty и ценой на момент покупки

  • Ограничения: FK, NOT NULL, CHECK (qty > 0), UNIQUE там, где нужно

  • Типы: numeric или копейки для денег, timestamptz для времени, статус через CHECK или enum

  • Индексы на FK и под частые запросы (заказы клиента по дате)

  • Платежи отдельной таблицей с идемпотентным внешним id от платёжки

Что могут спросить следом

  • Как хранить адрес доставки, если клиент его потом поменяет?
  • Как сделать историю смены статусов заказа?
  • Что изменится, если товары бывают в разных вариантах (размер, цвет)?

Разбор

Базовые сущности: customers, products, orders, order_items, payments. Заказ ссылается на клиента, позиции на заказ и товар, первичный ключ позиции (order_id, product_id) или свой id, если один товар может быть в заказе дважды с разными опциями. В позиции храню qty и price на момент покупки: это факт сделки, он не должен меняться при смене цены. Адрес доставки тоже копирую в заказ по той же причине. Деньги в numeric(12,2) или в копейках, время в timestamptz, статус заказа через CHECK со списком значений. Ограничения: внешние ключи, NOT NULL, CHECK (qty > 0). Индексы на внешних ключах и под частый запрос «заказы клиента по дате»: (customer_id, created_at DESC). Платежи отдельной таблицей, потому что у заказа может быть несколько попыток оплаты и возвраты; у платежа уникальный id операции из платёжной системы, чтобы повторный webhook не провёл оплату дважды. Историю статусов храню отдельной таблицей событий.

Ответьте сами, а не прочитайте

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