Приходилось ли работать с базами данных?
Что проверяют
Работали ли вы с базой напрямую и знаете ли особенности подхода в Go.
Как отвечать
В Go принято работать ближе к SQL, чем в других экосистемах, и это стоит проговорить.
Стандартный слой это интерфейс из стандартной библиотеки плюс драйвер. Для PostgreSQL это обычно отдельная библиотека, дающая как совместимый драйвер, так и собственный интерфейс с поддержкой родных типов и пакетных запросов.
Пул соединений встроен в стандартный слой, и его обязательно настраивают: максимальное число соединений, число простаивающих, время жизни. Значения по умолчанию неограниченные, и под нагрузкой это упирается в лимит соединений базы.
Контекст в каждом запросе: без него отмена запроса не работает, и запрос продолжит выполняться, даже когда клиент уже ушёл.
Подходы к запросам и выбор между ними:
- чистый стандартный слой: полный контроль, но много ручного разбора строк;
- расширение с разбором в структуры: убирает шаблонный код, оставляя запросы вашими;
- генератор кода из SQL: вы пишете запросы, инструмент генерирует типобезопасные функции. Очень популярный в сообществе подход, потому что сохраняет прозрачность SQL и убирает рутину;
- полноценная ORM: встречается, но в сообществе к ней относятся сдержанно, потому что она скрывает запросы, а именно их прозрачность здесь ценят.
Транзакции: начало, отложенный откат сразу после, подтверждение в конце. Забытый откат при раннем возврате не возвращает соединение в пул, и это классическая утечка.
Мелочи, о которых спрашивают: обработка отсутствия строк как отдельной ошибки, работа с пустыми значениями через специальные типы или указатели, подготовленные выражения, пакетная вставка.
Миграции отдельным инструментом и отдельным шагом выкладки. Тестирование с настоящей базой в контейнере.
Где спотыкаются
Не настраивают пул и упираются в лимит соединений.
Забывают отложенный откат транзакции.
Не передают контекст в запросы.
Не отличают отсутствие строк от настоящей ошибки.