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

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

Аналитика спрашивают не про синтаксис ради синтаксиса, а про переносимость запросов и витрин. В компании обычно живёт сразу несколько хранилищ, и важно, заметите ли вы, что одинаковый с виду запрос считает в них разные числа.

Как отвечать

Перечислите системы, с которыми работали, и покажите, где именно они расходятся:

• даты: date_trunc в PostgreSQL, dateadd и datediff в диалекте Microsoft, свои функции округления периода в ClickHouse, разные правила начала недели;
• приведение типов: где-то попытка превратить мусор в число даёт ошибку, где-то пустое значение, и это тихо меняет итог агрегата;
• ограничение выборки: limit против top, причём место в запросе тоже разное;
• окна есть почти везде, но именованные окна, отбор по результату окна и границы рамки поддержаны неодинаково;
• аналитические движки добавляют своё: приближённый подсчёт уникальных, массивы и их разворачивание, семплирование.

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

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

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

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

Третья: называть MySQL стандартом, а обобщённые табличные выражения считать изобретением одной системы. Это часть стандарта, поддержанная почти всеми, и такая путаница выдаёт поверхностное знакомство с темой.