Какие редакторы использовать при работе с базой данных и локально
Что проверяют
Насколько устоялось ваше рабочее окружение и умеете ли вы работать с базой не только через ORM. Следом обычно спрашивают, как вы смотрите план медленного запроса или подключаетесь к базе на сервере без графики.
Как отвечать
Назовите связку, которой пользуетесь сами, и коротко объясните выбор:
- редактор кода: PyCharm или VS Code с расширениями Python и Pylance. Важно не название, а что вы в нём делаете: отладчик с точками останова, запуск тестов
pytest, интерпретатор изvenvилиuv,ruffдля линтинга и форматирования; - клиент базы: DataGrip или встроенные инструменты баз данных в платном PyCharm, DBeaver как бесплатный клиент под многие СУБД, pgAdmin для PostgreSQL. На сервере консольные
psqlилиpgcli; - локальная база: поднимается в Docker через
docker composeтой же версии, что на проде. Схема меняется миграциями Alembic илиmanage.py migrateв Django, строка подключения лежит в.env, не в коде; - что делаете в клиенте:
EXPLAIN ANALYZEдля медленных запросов, проверка индексов и блокировок, сверка данных после миграции; - Jupyter: если в работе есть анализ данных, упомяните ноутбуки и
pandas.read_sql.
Добавьте, как видите SQL, который генерирует ORM: echo=True в create_engine у SQLAlchemy или django-debug-toolbar в Django. Это сильный сигнал, что вы замечаете N+1 и лишние запросы.
Если с каким-то клиентом опыта нет, так и скажите: работали через psql и PyCharm, DBeaver видели на учебном проекте. Честный ответ про два инструмента лучше списка из десяти.
Где спотыкаются
Перечисляют всё подряд, включая Atom. Его закрыли в 2022 году, и упоминание выдаёт ответ, выученный по старой статье.
Говорят только про редакторы и молчат про базу: «данные смотрю через ORM в шелле». Интервьюер слышит, что вы не видите генерируемый SQL и не умеете разбирать план запроса.
Меняют схему руками через GUI-клиент на общей или боевой базе. Изменения не попадают в миграции, окружения расходятся. Хороший ответ: клиент для чтения и отладки, схема только через миграции.