Это плохой пример или плохой дизайн базы данных: -).
Вы, вероятно, не должны хранить первые (или любые) имена каким-либо образом, который потребует от вас использования LIKE
. Вы должны иметь в виду, что таблицы почти всегда читаются гораздо чаще, чем написаны, и оформляют соответственно.
Это означает, что вы хотите, чтобы стоимость была при вставке или обновлении, а не при выборе. Функции для каждой строки, такие как upper(name)
, плохо масштабируются до подходящих баз данных корпоративного класса.
На мой взгляд, для DB2 вы должны иметь следующее:
- триггер вставки / обновления, который удаляет начальные и конечные пробелы из имени (и фамилии).
- сгенерированный столбец, который будет содержать имена в верхнем регистре (это использует больше памяти, но обычно это лучше, чем тратить время). Я не уверен, что UDB9 сгенерировал столбцы (DB2 / z имеет), но вы можете сделать это в том же триггере вставки / обновления. По сути, это дополнительный столбец, для которого всегда задана заглавная версия другого поля.
- индекс сгенерированного столбца, а не исходного столбца.
Таким образом, ваши выборы будут кричать вместе с такими запросами, как (большие и некрасивые, но эффективные):
select * from tbl
where generatedname = 'SAM'
or generatedname = 'SAMUEL'
or generatedname = 'SAMANTHA'
or generatedname = 'WILL'
or generatedname = 'WILLIAM'
or generatedname = 'WILLOMENA'
или (менее большой и некрасивый, такой же эффективный и более близкий к исходному запросу по назначению):
select * from tbl
where generatedname like 'SAM%'
or generatedname like 'WILL%'
используя всю мощь оптимизатора запросов (DB2 и другие СУБД, я думаю, все еще могут легко оптимизировать 'XX%', если поле проиндексировано).
Я не большой поклонник использования LIKE
для любых приличных размеров столов, хотя иногда нет большого выбора. Я не могу вспомнить ни одной жизнеспособной ситуации, в которой вы хотели бы искать "%SAM%"
, и это приводит к невозможности использовать оптимизатор в полной мере.