От чего зависит, попадут ли две текстовые строки в одну группу при GROUP BY?
Это зависит от правил сравнения значений соответствующего типа, прежде всего от колляции и особенностей конкретной СУБД. Колляция определяет, например, учитывается ли регистр и как сравниваются символы; поэтому строки, визуально похожие или даже совпадающие для пользователя, могут попасть в одну группу либо в разные.
GROUP BY появился как механизм формирования групп по значениям измерений перед вычислением агрегатов. Для чисел и дат правила сравнения обычно очевидны, но для текста требуется учитывать язык, алфавит, регистр и правила сортировки, поэтому SQL опирается на настройки сравнения, заданные типом данных, столбцом, выражением или окружением запроса.
Отчёт может неожиданно содержать две строки для условно одинаковых названий, например для вариантов, различающихся регистром или диакритикой. Обратная ситуация тоже опасна: разные значения могут быть объединены в одну группу, из-за чего количество записей, суммы и другие агрегаты окажутся искажены.
Особенно рискованно полагаться на поведение по умолчанию при переносе запроса между СУБД, базами с разными настройками или столбцами с разными правилами сравнения. Внешний вид текста сам по себе не показывает, как именно СУБД классифицирует значения.
При группировке СУБД вычисляет ключ группировки для каждой строки и сравнивает ключи по правилам, применимым к их типу. Для текстовых выражений значимы колляция, кодировка и правила сравнения; в зависимости от них регистр, акценты и некоторые языковые варианты могут считаться значимыми или игнорироваться.
Важно различать правила сортировки и равенства: конкретная СУБД связывает их с колляцией по своим правилам, но нельзя переносить выводы одной СУБД на другую без проверки документации. Также результат может зависеть от колляции самого столбца, явного назначения колляции выражению и настроек базы или соединения.
Если бизнес-правило требует собственной нормализации, её следует выразить явно: например, привести строки к единому регистру, удалить или преобразовать особые символы и только затем группировать. Это делает намерение запроса понятнее, но может изменить смысл данных, усложнить использование индекса и привести к потере различий, которые действительно важны.
Для надёжного отчёта нужно заранее определить, что считается одним значением: точное совпадение, совпадение без учёта регистра, языковое равенство или отдельная бизнес-нормализация. Затем следует закрепить это правило на уровне схемы или явно в запросе и проверить пограничные случаи тестовыми данными.
В отчёте по городам появились отдельные группы для значений Москва и москва. Рассматривались три варианта: оставить поведение по умолчанию, изменить колляцию столбца или группировать по нормализованному выражению.
Первый вариант был отклонён: результат зависел от настроек окружения. Изменение колляции столбца давало единое правило для всех запросов, но затрагивало существующие сравнения и сортировки. Выбрали явную нормализацию в отчётном слое, потому что только этот отчёт требовал нечувствительности к регистру; при этом отдельно проверили индексацию и сохранили исходное написание для отображения.
Результат стал предсказуемым: строки объединялись по согласованному бизнес-правилу, а отображаемое название выбиралось отдельно. Это также предотвратило смешение ключа группировки с текстом, который показывается пользователю.
Они используют связанные правила сравнения, но бизнес-вывод нельзя делать только по визуальному порядку строк. Нужно учитывать тип выражения и применённую колляцию; в конкретной СУБД детали равенства и сортировки могут различаться. Поэтому для критичного отчёта правило группировки проверяют явно, а не выводят из того, как значения отсортировались.
Не всегда. Приведение к нижнему регистру решает только задачу регистра и может зависеть от языковых правил. Оно не обязательно решает различия в диакритике, пробелах, Unicode-нормализации или других вариантах записи. Кроме того, функция над столбцом может помешать использованию обычного индекса, если СУБД не поддерживает подходящий функциональный или вычисляемый индекс.
Нет. Если колляция или нормализация объединяет несколько исходных строк, результат группы представляет класс эквивалентных значений, а не обязательно одну исходную строку. Для выбора отображаемого названия требуется отдельное детерминированное правило, иначе при наличии нескольких вариантов написания выбор может быть неоднозначным или зависеть от плана выполнения.