База данных нечувствительный к регистру индекс?

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

Затем Вы могли сделать мультипункт где:

hash = [compute hash key for 'SAN FRANCISCO']

SELECT county 
FROM city 
WHERE cityHash = hash 
  AND UPPER(name) = 'SAN FRANCISCO' ;

С другой стороны, пройдите свое руководство дб и посмотрите на опции для создания индексов таблицы. Могло бы быть что-то полезное.

Oracle поддерживает функциональные индексы. Их канонический пример:

 create index emp_upper_idx on emp(upper(ename));  

Короткий ответ, нет.

Длинный ответ, да, если Вы работаете на мейнфрейме, но Вы не, таким образом, необходимо использовать другой обман.

DB2 (с DB2/LUW v8) теперь генерировал столбцы, таким образом, Вы можете:

CREATE TABLE tbl (
    lname  VARCHAR(20),
    fname  VARCHAR(20),
    ulname VARCHAR(20) GENERATED ALWAYS AS UPPER(lname)
);

и затем создайте индекс на ulname. Я не уверен, что Вы собираетесь получить его более простой, чем это.

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

Посмотрите здесь для деталей.

PostgreSQL также поддерживает индексацию результатов функции:

CREATE INDEX mytable_lower_col1_idx ON mytable (lower(col1));

Единственная другая опция, о которой я могу думать, состоит в том, чтобы денормализовать Ваши данные немного путем создания другого столбца для содержания прописной версии (обновленный триггерами) и индекс это. Blech!

Я не знаю, работало ли это в DB2, но я скажу Вам, как я сделал бы это в SQL Server. Я думаю способ, которым делает MSSQL это - стандарт ANSI, хотя определенные строки сопоставления могут отличаться. Так или иначе, если можно сделать, это, не повреждая остальную часть приложения - является там другими местами, где столбец "имени" должен быть чувствительным к регистру? - пытаются делать тот целый столбец нечувствительным к регистру путем изменения сопоставления, затем индексируют столбец.

ALTER TABLE city ALTER COLUMN name nvarchar(200) 
    COLLATE SQL_Latin1_General_CP1_CI_AS

... где "nvarchar (200)" помогает для того, что Ваш тип данных текущего столбца. Часть "CI" строки сопоставления - то, что отмечает ее как нечувствительную к регистру в MSSQL.

Объяснить... мое понимание то, что индекс сохранит значения в порядке сопоставления индексированного столбца. Создание сопоставления столбца быть нечувствительным к регистру заставило бы индекс сохранить 'Сан-Франциско', 'САН-ФРАНЦИСКО' и 'Сан-Франциско' все вместе. Затем Вам придется просто удалить "ВЕРХНИЙ ()" от Вашего запроса, и DB2 должен знать, что может использовать Ваш индекс.

Снова, это базируется только на том, что я знаю о SQL Server плюс пара минут, смотря на спецификацию SQL-92; это может или не может работать на DB2.

DB2 не силен относительно сопоставления. И это не имеет функциональных индексов.

Предложение Niek Sanders работало бы, если можно признать, что хеширование должно произойти в приложении (поскольку DB2 не имеет SHA или функций MD5, насколько я знаю).

Однако на вашем месте я создал бы осуществленное представление (MQT == Осуществленная Таблица запроса, в db2 языке) использующий CREATE TABLE AS, добавив столбец с предварительно вычисленным прописным вариантом имени.Примечание: Можно добавить индексы к осуществленным представлениям в DB2.