Почему нельзя пихать везде DISTINCT ON…

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

Так вот, когда я сделал новый скрипт, то начал сравнивать данные с текущей визуализацией: где-то сходилось, а где-то были расхождения. Сначала я подумал, что где-то ошибся, но странно — много где сходится ведь.

В данном проекте происходит миграция с Greenplum на ClickHouse, поэтому есть свои особенности, на которые я изначально и подумал. Одна из них: нужно делать ORDER BY уникальным, чтобы при переносе в колоночную систему данные приходили в полном объеме и правильном порядке. Когда я выставил сортировку и несколько раз подряд запустил скрипт, то заметил, что расчетные значения меняются.

Я залез в текущий скрипт и увидел DISTINCT ON и UNION. Суть в том, что DISTINCT ON выбирал только одну строку из нескольких, а набор для сортировки был НЕуникальный, так что каждый раз расчеты прилетали разные. Раньше я не заметил этого, потому что по сути делал новый запрос, а не переделывал текущий.

В общем, суть в том, что DISTINCT ON надо использовать осознанно, например, как альтернативу ROW_NUMBER(), о которой писал в другой заметке, а не для того, чтобы просто убрать дубли. Ведь полученное уникальное значение может быть рандомным, а следовательно — некорректным.

Связи:

📌 DISTINCT ON: Как выбирать нужное, не нумеруя лишнего