База данных в бэкенде: SQL, NoSQL и индексы для собеседования

Почему база данных — главная тема на собеседовании бэкендера?

На любом техническом собеседовании для бэкенд-разработчика рано или поздно всплывают вопросы про базы данных: индексация, проектирование схем, пулы соединений. Почему так много внимания уделяется тому, что кажется просто «хранилищем»? Ответ прост: ваш API-код можно переписать за день, бизнес-логику — отрефакторить за спринт, но плохая схема базы данных с реальными данными — одна из самых дорогих ошибок в разработке. Миграция живых данных, часто без остановки системы, — это кошмар, который не прощает небрежности. Джуниора оценивают по коду, сеньора — по работе с данными. Эта статья — ваш гайд по ключевым аспектам работы с базами данных, которые проверяют на собеседованиях.

SQL vs NoSQL: не религия, а инструмент

Многие новички спрашивают: «Что лучше — SQL или NoSQL?» И хотят один универсальный ответ. Но правда в том, что универсального «лучшего» не существует. Есть только «лучшее для конкретной задачи». Тот, кто утверждает обратное, никогда не работал с обоими подходами в продакшене. Вот краткое сравнение:

• SQL (PostgreSQL, MySQL) — лучше всего подходит для данных со сложными связями и строгой согласованностью. Гарантирует ACID-транзакции. Схема фиксирована. Масштабируется вертикально, затем через реплики и шардирование. Примеры: банковские проводки, заказы, пользователи.
• NoSQL (MongoDB, Cassandra, DynamoDB) — для огромных масштабов, гибких схем и простых паттернов доступа. Обычно обеспечивает согласованность в конечном счёте. Схема гибкая, может меняться под каждый документ. Масштабируется горизонтально. Примеры: сообщения чата, ленты активности, логи IoT.

Запомните главный принцип: не спрашивайте «какая БД лучше», спрашивайте «что нужно этим конкретным данным?». Платёжная таблица требует ACID — это SQL, безальтернативно. Лог сообщений с миллиардами записей и простым запросом «последние 50 сообщений» не нуждается в JOIN — это NoSQL. В серьёзном продакшене часто используют обе СУБД для разных частей данных. Это не оверинжиниринг, а правильный выбор инструмента.

Проектирование схемы: как не ошибиться, когда данные ещё не определены

В начале проекта вы часто не знаете точную структуру данных. Поле — строка, число или enum? Застываете в нерешительности? Вот несколько практических советов:

• Выбирайте более строгий тип, который можно ослабить позже. Ослабить ограничение на живой таблице — быстрая миграция. Ужесточить после накопления «мусора» (например, сделать NOT NULL, когда есть NULL) — гораздо больнее.
• Используйте JSON/JSONB для действительно изменяемых полуструктурированных данных (например, метаданные товаров, которые различаются по категориям). Современный PostgreSQL отлично это поддерживает: вы получаете реляционные гарантии для ключевых полей и гибкость для остального.
• Не гадайте с длиной VARCHAR. Не ставьте 255 «на всякий случай». Подумайте о реальных данных: email имеет разумный максимум, URL — нет, короткий код — ровно 8 символов. Правильный размер влияет на стоимость хранения и эффективность индексов.

Суть: настоящий скилл — не предсказать будущее, а спроектировать так, чтобы исправление ошибки заняло пять минут, а не выходные.

База данных вам тоже не доверяет: ограничения как защита

Фронтенд не доверяет пользователю, бэкенд не доверяет фронтенду, а база данных — самая параноидальная из всех — не доверяет разработчику бэкенда. И правильно делает. Ошибки случаются: пропущенная валидация, спешная фича, ночной хотфикс. Задача базы — быть последней линией обороны, которая не примет мусор, как бы уверенно код его ни передавал. Поэтому мы ставим ограничения прямо на схему:

• NOT NULL — для полей, которые всегда должны иметь значение. Пользователь без email, заказ без суммы — это должно быть структурно невозможно.
• UNIQUE — для полей, которые не должны повторяться. Два аккаунта с одним email — катастрофа. Уникальное ограничение делает это невозможным на уровне БД.
• Nullable осознанно — не каждое поле обязано быть NOT NULL. Отчество может отсутствовать — честный NULL лучше, чем пустая строка или «N/A».
• ENUM или внешний ключ — для ограничения набора значений. Вместо строки для роли используйте role ENUM('user', 'admin', 'moderator'). Тогда опечатка «admni» будет отвергнута базой, а не пропущена из-за бага в коде.

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

Бэкенд не доверяет фронтенду: валидация на каждом рубеже

Пользовательский ввод → фронтенд-валидация (удобство, ноль безопасности) → API-запрос → бэкенд-валидация (настоящий шлюз) → запись в БД → ограничения БД (последний необходный рубеж) → сохранённые данные. Фронтенд-валидация нужна только для хорошего UX — любой может обойти её через Postman или curl. Бэкенд должен полностью перепроверять всё: типы, длины, форматы, бизнес-правила. А ограничения БД — финальная защита от багов в самом бэкенде. Это не избыточность, а многоуровневая оборона от разных типов отказов.

Пул соединений: почему без него никуда

Открытие соединения с БД — не бесплатная операция: рукопожатие, аутентификация, выделение ресурсов. Если для каждого запроса открывать новое соединение, вы платите эти десятки миллисекунд постоянно. Пул соединений — это набор заранее открытых и переиспользуемых соединений. Без пула: запрос → открыть → выполнить → закрыть (медленно). С пулом: запрос → взять из пула → выполнить → вернуть в пул (быстро). Это как аренда автомобилей вместо покупки нового под каждую поездку. Настройка пула — базовая практика, без которой продакшен будет тормозить.

Что делать прямо сейчас

1. Пересмотрите схемы своих таблиц: добавьте NOT NULL, UNIQUE, ENUM там, где это уместно. 2. Если используете SQL, попробуйте JSONB для гибких полей. 3. Настройте пул соединений (например, psycopg2.pool или SQLAlchemy). 4. На собеседовании не говорите «SQL лучше NoSQL» — объясните, для каких задач каждый подходит. Практикуйтесь — и данные будут на вашей стороне.