Создавали ли таблицы и индексы в базах данных?

Что проверяют

Проектировали ли вы схему сами или только писали запросы к готовой. Ответ должен показывать, что вы думаете про типы, ограничения и стоимость индекса.

Как отвечать

Коротко и через конкретный случай.

> «Да, схему своих сервисов проектирую сам, миграции через Liquibase. Последний раз заводил таблицу откликов: первичный ключ, внешние ключи на вакансию и пользователя с on delete cascade, уникальный индекс по паре (user_id, job_id), чтобы не было двойных откликов, и составной индекс по (user_id, created_at) под ленту в кабинете. Частичный индекс по активным записям, потому что архив в выборку не попадает».

Что уместно назвать по существу:

• типы: не varchar(255) по привычке, а по смыслу. Деньги это numeric, а не float; время с зоной; идентификаторы uuid или bigint;
• ограничения: not null по умолчанию, check на допустимые значения, внешние ключи с явным поведением при удалении, уникальность там, где она есть по бизнесу;
• индексы: под конкретные запросы, а не «на всякий случай». Составной с правильным порядком колонок, частичный на подмножество, уникальный как ограничение целостности;
• миграции: только вперёд, через инструмент, с оглядкой на блокировки. На большой таблице добавление колонки с default переписывает её целиком, а индекс строят concurrently.

Где спотыкаются

Заводят индексы на все колонки и замедляют запись.

Хранят деньги в float и получают расхождение копеек.

Не ставят внешние ключи, полагаясь на код приложения.

Не задумываются о блокировках при миграции и роняют прод на ALTER TABLE.