Process Mining
Mais recente
falso
Imagem de fundo do banner
Process Mining
Última atualização 17 de abr de 2024

SQL differences between Snowflake and SQL Server

SQL Server vs. Snowflake

In a local development environment, transformations are run on SQL Server, while Snowflake is used in Process Mining Automation CloudTM. Although most SQL statements will work both on SQL Server and Snowflake, there can be slight differences in syntax, which may lead to different return results.

Para escrever instruções SQL que funcionem em ambos os sistemas de banco de dados:

  • Escreva os nomes dos campos entre aspas duplas, por exemplo Table."Field".
  • Evite o uso de funções SQL diferentes no Snowflake e no SQL Server, por exemplo string_agg() e listagg().
    O pacote pm_utils vem com um conjunto de funções que funcionam em ambos os tipos de banco de dados, consulte Diversos bancos de dados. Por exemplo, em vez de usar string_agg() ou listagg(), pm_utils.string_agg() resultará no mesmo comportamento para ambos os bancos de dados. Se pm_utils não contiver a função desejada, uma instrução Jinja deverá ser criada para garantir que a função correta seja chamada em cada banco de dados.

String concatenation

Para combinar strings, use a função pm_utils.concat() . Isso produzirá os mesmos resultados para SQL Server e Snowflake.
Exemplo: pm_utils.concat("This is a nice string", null) = "This is a nice string" A concatenação de strings não deve ser feita com operadores como + ou ||, pois são diferentes para ambos os bancos de dados (Snowflake usa || e SQL Server usa +). Além disso, a função concat() padrão tem comportamento diferente em ambos os sistemas:

SQL Server

Snowflake

null os valores serão ignorados e tratados como uma string vazia.
null os valores farão com que todo o resultado seja null.

Ordenação

A classificação é tratada de forma diferente no Snowflake e no SQL Server.

Exemplo: ... order by "Attribute_1" desc, "Attribute_2" ...

Valores nulos

SQL Server

Snowflake

null o padrão será ordenado primeiro (crescente)
null o padrão será classificado por último (crescente)

Handling capital letters

SQL Server

Snowflake

as maiúsculas são classificadas como esperado (AaBbCc)

primeiro classifica por maiúsculas, depois por não maiúsculas (ABCabc)

Dashes

Exemplo: -Accountant-

SQL Server

Snowflake

travessões são ignorados na classificação (portanto, '-Contador-' é tratado da mesma forma que 'Contador')

os traços serão classificados no topo

Whitespace handling

Quando você agrupa por valores “A“ e “ A“, isso é visto como um valor no SQL Server, mas como dois valores diferentes no Snowflake. Portanto, o corte é recomendado se seus dados puderem causar esse problema.

Case sensitivity

Por padrão, o SQL Server não diferencia maiúsculas de minúsculas, enquanto o Snowflake diferencia maiúsculas de minúsculas. Isso significa que Table."Field" = "Some_value" e Table."Field" = "SOME_VALUE" retornarão o mesmo conjunto de resultados no SQL Server, mas possivelmente dois conjuntos de resultados diferentes no Snowflake.

É recomendável alterar o comportamento do banco de dados local do SQL Server para corresponder ao comportamento do Snowflakes, a fim de evitar problemas. Isso pode ser feito definindo o agrupamento do banco de dados para um valor que diferencia maiúsculas de minúsculas.

  • SQL Server vs. Snowflake
  • String concatenation
  • Ordenação
  • Valores nulos
  • Handling capital letters
  • Dashes
  • Whitespace handling
  • Case sensitivity

Was this page helpful?

Obtenha a ajuda que você precisa
Aprendendo RPA - Cursos de automação
Fórum da comunidade da Uipath
Logotipo branco da Uipath
Confiança e segurança
© 2005-2024 UiPath. All rights reserved.