SQL « JOIN по текстовому полю

Как вы относитесь к JOIN`ам по текстовым полям в реляционных БД?
Где использовали? Какая скорость работы? Какие подводные камни?

1 ответов


Мы в DWH использовали. Таблицы денормализованы, автоматически-генерируемые суррогатные ключи не используются: важно сохранить человеко-понятность данных, логичность и эквивалентность на разных средах. Вместо этого используются естественные ключи (например, уникальный логин пользователя, номер телефона в таблице телфеонов и т.п.), либо задаются по справочнику (т.е. создается специальный справочник со значениями типа MSK->Москва, SPB->Санкт-Пертербург и т.д. - это гарантирует, что строка будет короткой, строго 3 символа, и везде одинаковой). Длинное значение строки приводится к короткому при загрузке данных в DWH на этапе ETL один раз. Далее значение не меняется, легко интерпретируется человеком прямо по сырым данным, 3-байтная строка не отличается от number-а.

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

Минусы: хеш по длинной строке строится дольше (для соединений по хешу), данные занимают больше места, индексы большие и менее эффективные. Конечно, не стоит в качестве ключа использовать длинные строки. Но в пределах 10-20 символов - почему бы и нет.

Подводные камни в справочниках. Кто-то должен при появлении новых данных дозаполнять справочники. Не успели вовремя - будут кривые данные. Заполнили не в том регистре или кодировке - еще проблема. Если некая автоматика тупо обрезает длинную строку до 10 символов - это тоже плохо: рано или поздно появятся строки, различия в которых начнутся с 11-го символа, а первые 10 будут одинаковыми.

В обычных LTP базах внимания к сырым данным меньше. Врятли кто-то из людей захочет вручную генерировать ключи для своих данных. Но в некоторых случаях, если есть удобный естественный ключ, думаю, можно применить. Например, логин пользователя в некоторых случаях удобнее использовать, нежели некий непонятный номер. Аналогично код региона, RGB код цвета, номер ICQ и т.д.