Есть ли опыт проектирования базы данных без ORM

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

Умеете ли вы думать о схеме в терминах таблиц, ключей и ограничений, а не классов моделей. ORM многое прячет, и интервьюеру важно понять, что вы видите за ней реальный SQL. Следом обычно просят рассказать про конкретную схему или про то, как вы вели миграции без ORM.

Как отвечать

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

Каркас, в который удобно уложить историю:

• схема: нормализация до третьей нормальной формы и осознанная денормализация там, где её оправдывает чтение. Первичные ключи bigint generated always as identity или UUID, внешние ключи с явным ON DELETE, ограничения NOT NULL, UNIQUE, CHECK прямо в базе;
• типы: timestamptz вместо timestamp, numeric для денег, jsonb только там, где структура действительно плавает;
• доступ из Python: psycopg 3 или asyncpg, параметризованные запросы (%s в psycopg, $1 в asyncpg), явные транзакции. Если нужен построитель запросов без моделей, подходит SQLAlchemy Core;
• миграции: пронумерованные SQL-файлы, Alembic с op.execute(), yoyo-migrations или Flyway. Важно, что миграции версионируются и применяются одинаково на всех окружениях;
• производительность: индексы под конкретные запросы и проверка через EXPLAIN ANALYZE.

Если проектировали только через Django ORM или SQLAlchemy ORM, скажите это прямо и покажите, что видите SQL за ними: читали сгенерированные запросы (queryset.query, django-debug-toolbar), писали RunSQL в миграциях, ловили N+1. Честное «с нуля без ORM не проектировал, но вот как я бы сделал схему для вашего случая» звучит лучше придуманного проекта.

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

Собирают SQL f-строками. Это SQL-инъекция, и такой пример в рассказе про «опыт без ORM» перечеркнёт весь ответ.

Рассказывают только про CREATE TABLE и молчат про ограничения. Без внешних ключей и CHECK целостность держится на честном слове кода.

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