- Notas de versão
- Antes de começar
- Introdução
- Gerenciamento de acesso
- Como trabalhar com aplicativos de processo
- Criação de apps de processo
- Carregamento de dados
- Carregamento de dados
- Retrieving the SQL Server database parameters
- Configuração de uma conta do SQL Server para upload de dados usando um extrator
- Loading data using Theobald Xtract Universal
- Requisitos do Sistema
- Configuração do DataBridgeAgent
- Configuring CData Sync
- Adição de um conector personalizado ao DataBridgeAgent
- Uso do DataBridgeAgent com o Conector SAP para o Acelerador de Descoberta Purchase-to-Pay
- Uso do DataBridgeAgent com o Conector SAP para o Acelerador de Descoberta Order-to-Cash
- Personalização de aplicativos de processo
- Transformações de dados
- Edição de transformações de dados em um ambiente local
- Setting up a local test environment
- SQL differences between Snowflake and SQL Server
- Designing an event log
- Structure of transformations
- Tips for writing SQL
- ModeloUm modelo de aplicativo
- Modelo de aplicativo Purchase-to-Pay
- Modelo de aplicativo Order to Cash
- Basic troubleshooting guide
SQL differences between Snowflake and SQL Server
Em um ambiente de desenvolvimento local, as transformações são executadas no SQL Server, enquanto o Snowflake é usado no Process Mining Automation Suite. Embora a maioria das instruções SQL funcione no SQL Server e no Snowflake, pode haver pequenas diferenças na sintaxe, o que pode levar a resultados retornados diferentes.
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()
elistagg()
.O pacotepm_utils
vem com um conjunto de funções que funcionam em ambos os tipos de banco de dados, consulte Vários bancos de dados. Por exemplo, em vez de usarstring_agg()
oulistagg()
, opm_utils.string_agg()
resultará no mesmo comportamento para ambos os bancos de dados. Sepm_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.
pm_utils.concat()
. Isso produzirá os mesmos resultados para SQL Server e Snowflake.
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 |
---|---|
Os valores
null serão ignorados e tratados como uma string vazia.
|
Valores
null farão com que todo o resultado seja null .
|
A classificação é tratada de forma diferente no Snowflake e no SQL Server.
... order by "Attribute_1" desc, "Attribute_2" ...
SQL Server |
Snowflake |
---|---|
null padrão será classificado primeiro (crescente)
|
null por padrão será ordenado por último (ascendente)
|
SQL Server |
Snowflake |
---|---|
as maiúsculas são classificadas como esperado (AaBbCc) |
primeiro classifica por maiúsculas, depois por não maiúsculas (ABCabc) |
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.
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.