¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Configuração de sensibilidade a maiúsculas e minúsculas no HANA: É recomendável desativá-la?

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 8 Vistas
0
Cargando...

Olá a todos!

Temos uma visualização no HANA que os usuários estão acessando através do Microstrategy. Todos os campos, como PLANT (WERKS), são sensíveis a maiúsculas e minúsculas. Por exemplo, se a planta se chama 'XYZ1', então a seguinte consulta SQL NÃO retorna nenhum resultado;

select * from TABLENAME where WERKS = 'xyz1'

Agora meu desenvolvedor do Microstrategy está dizendo que outras bases de dados que ele consome não são sensíveis a maiúsculas e minúsculas e que essa configuração é tipicamente feita no nível do banco de dados. Portanto, minha pergunta é dupla;

1) Existe uma configuração de sensibilidade a maiúsculas e minúsculas no nível do banco de dados no HANA?

2) Se essa opção estiver disponível, realmente faz sentido desativar essa sensibilidade?

Obrigado,

-Patrick

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Olá Lars,

Obrigado pela informação.

Isso é muito útil para alguém com pouca experiência em modelagem de bancos de dados como eu, para aprender dicas e truques que os manuais oficiais geralmente não incluem.

Então, voltando ao problema original: em um caso real, onde por padrão não existe uma coluna upper_name em nossa tabela de fatos, como deveria ser criado esse "Índice baseado em funções" no HANA? Você poderia criar esse índice personalizado com o comando CREATE INDEX ou outro comando? Ou seria necessário alterar a tabela original para incluí-lo?

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Além do comentário de Stefan, a solução clássica para este requisito seria criar o que a Oracle chama de Índice Baseado em Funções.

É bastante similar às colunas geradas no SAP HANA e permitiria ao otimizador aproveitar uma estrutura de Índice existente.

No SAP HANA, o otimizador SQL é inteligente o suficiente para perceber que já existe uma versão em maiúsculas pré-calculada dos dados neste 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;

NAME UPPER_NAME
Lars LARS
Mara MARA
Josh JOSH
Caroline CAROLINE

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, a coluna gerada é usada aqui sem a necessidade de recodificar a instrução SQL.

Agora, para o uso de LIKE em vez de igual, a função também funciona:

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

NAME UPPER_NAME
Lars LARS
Mara MARA
Caroline CAROLINE

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%''

Portanto, os velhos truques ainda funcionam com o SAP HANA .

Se isso proporciona um desempenho muito melhor é algo que realmente deve ser testado com dados reais.

A grande diferença no SAP HANA em comparação com os DBMS orientados a linhas é que a avaliação da condição WHERE funciona apenas no dicionário (os valores únicos de cada coluna) e não em cada linha individual.

Saudações, Lars

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Henrique,

Basicamente, trata-se da forma como os caracteres são comparados. Você pode usar comparações binárias de caracteres (= configuração padrão) ou comparações linguísticas no Oracle (não sei como é tratado internamente em outros sistemas de gerenciamento de bancos de dados relacionais). Os caracteres são comparados de acordo com seu valor binário em comparação binária, caso contrário, o código numérico de cada caractere não precisa ser idêntico para corresponder.

Você terá até mesmo um desempenho ruim (buscas únicas de índices ou varreduras de intervalos impossíveis) ao usar linguagem, se não criar um índice com a função nlssort (que é usada implicitamente). Existem também outras limitações (como coisas de mapas de bits e afins), mas isso seria muito longe por agora.

Saudações

Stefan

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Tópico interessante.

Depois de uma rápida pesquisa no Google, aparentemente o comportamento padrão varia de BD para BD.

O SQL Server aparentemente é insensível a maiúsculas e minúsculas por padrão, enquanto o Oracle aparentemente não é.

Uma coisa que a camada de BI poderia fazer é usar algo como

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

Em um RDBMS clássico, isso teria um desempenho terrível, pois não consideraria os índices existentes como na cláusula WHERE direta. No entanto, em um banco de dados em memória, não tenho certeza de qual seria a degradação de desempenho (se houver). Por favor, teste e nos informe.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?