Работали ли с диалектами SQL

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

Знаете ли вы, что объектное отображение не делает запросы переносимыми само собой, и переезжали ли вы между базами. Для Java-разработчика вопрос почти всегда сводится к Hibernate: интервьюер выясняет, понимаете ли вы, за что отвечает класс диалекта.

Как отвечать

Скажите, с какими базами работали, и сразу назовите места расхождений:

• генерация ключей: последовательности в PostgreSQL и Oracle против автоинкремента в MySQL, отсюда разный выбор стратегии GenerationType;
• постраничная выборка: limit и offset против fetch first ... rows only и старого приёма с номером строки;
• вставка с обновлением: on conflict, merge и on duplicate key update это три синтаксиса одной идеи;
• типы: jsonb, массивы и родной uuid есть не везде, логическое значение в Oracle исторически выражают числом;
• поведение: место пустых значений при сортировке, чувствительность сравнения строк к регистру, слияние пустой строки и null в Oracle.

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

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

Гоняют тесты на встроенной базе в режиме совместимости и верят, что проверили тот же диалект. Режим совместимости повторяет синтаксис, но не блокировки, не планы и не поведение конкурентных транзакций, поэтому проверять надо на настоящей СУБД в контейнере.

Вторая ошибка: путают диалект с драйвером. Драйвер отвечает за протокол и передачу значений, диалект за текст сгенерированного запроса, и ошибки у них выглядят совершенно по-разному.

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