Configuración de sensibilidad a mayúsculas y minúsculas en HANA: ¿Es recomendable desactivarla?

Además del comentario de Stefan, la solución clásica para este requisito sería crear lo que Oracle llama un Índice Basado en Funciones.

Es bastante similar a las columnas generadas en SAP HANA y permitiría al optimizador aprovechar una estructura de índice existente.

En SAP HANA, el optimizador SQL es lo suficientemente inteligente como para darse cuenta de que ya hay una versión en mayúsculas precalculada de los datos en este caso:

create column table bbb (name varchar(20)

, upper_name varchar(20) generated always as UPPER(name));

insert into bbb values ('Lars');

insert into bbb values ('Mara');

insert into bbb values ('Josh');

insert into bbb values ('Caroline');

select * from bbb;

EXPLAIN PLAN FOR select * from bbb where upper(name) = upper('LaRs');

OPERATOR_NAME   OPERATOR_DETAILS

COLUMN SEARCH   BBB.NAME, BBB.UPPER_NAME (LATE MATERIALIZATION)

COLUMN TABLE  FILTER CONDITION: BBB.UPPER_NAME = 'LARS'

Como podemos ver, la columna generada se usa aquí sin necesidad de volver a codificar la instrucción SQL.

Ahora, para el uso de LIKE en lugar de igual, la función también funciona:

select * from bbb where upper(name) like '%AR%';

EXPLAIN PLAN FOR select * from bbb where upper(name) like '%AR%';

OPERATOR_NAME   OPERATOR_DETAILS

COLUMN SEARCH   BBB.NAME, BBB.UPPER_NAME (LATE MATERIALIZATION)

COLUMN TABLE  FILTER CONDITION: BBB.UPPER_NAME LIKE ''%AR%''

Por lo tanto, los viejos trucos aún funcionan con SAP HANA .

Si esto proporciona un rendimiento mucho mejor es algo que realmente se debe probar con datos reales.

La gran diferencia en SAP HANA en comparación con los DBMS orientados a filas es que la evaluación de la condición WHERE solo funciona en el diccionario (los valores únicos de cada columna) y no en cada fila individual.

Saludos, Lars

Hola Henrique,

Básicamente, se trata de la forma en que se comparan los caracteres. Puedes utilizar comparaciones binarias de caracteres (= configuración predeterminada) o comparaciones lingüísticas en Oracle (no sé cómo se maneja internamente en otros sistemas de gestión de bases de datos relacionales). Los caracteres se comparan según su valor binario en caso de comparación binaria, de lo contrario, el código numérico de cada carácter no tiene que ser idéntico para coincidir.

Incluso tendrías un mal rendimiento (búsquedas únicas de índices o exploraciones de rangos no posibles) con el uso lingüístico, si no creas un índice con la función nlssort (que se utiliza implícitamente). También existen otras limitaciones (como cosas de mapas de bits y demás), pero eso sería demasiado lejos por ahora.

Saludos

Stefan

Tema interesante.

Después de buscar rápidamente en Google, al parecer el comportamiento predeterminado varía de DB a DB.

SQL Server aparentemente es insensible a mayúsculas y minúsculas por defecto, mientras que Oracle aparentemente no lo es.

Una cosa que la capa de BI podría hacer es usar algo como

WHERE UPPER("COLUMN") = UPPER(:criterio)

En un RDBMS clásico, esto tendría un rendimiento terrible ya que no consideraría los índices existentes como en la cláusula WHERE directa. Sin embargo, en una DB en memoria, no estoy seguro de cuál sería la degradación del rendimiento (si la hay). Por favor, pruébalo y háznoslo saber.