process-mining
latest
false
Important :
Veuillez noter que ce contenu a été localisé en partie à l’aide de la traduction automatique.
Process Mining
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 18 sept. 2024

SQL differences between Snowflake and SQL Server

SQL Server vs. Snowflake

Dans un environnement de développement local, les transformations sont exécutées sur SQL Server, tandis que Snowflake est utilisé avec Process Mining Automation CloudTM pour le secteur public. Bien que la plupart des instructions SQL fonctionnent à la fois sur SQL Server et Snowflake, il peut exister de légères différences dans la syntaxe, ce qui est susceptible d'entraîner des différences de résultats renvoyés.

Pour écrire des instructions SQL qui fonctionnent sur les deux systèmes de base de données :

  • Écrivez les noms de champ entre guillemets doubles, par exemple Table."Field" .
  • Empêcher l'utilisation de fonctions SQL différentes dans Snowflake et SQL Server, par exemple string_agg() et listagg() .
    Le package pm_utils est livré avec un ensemble de fonctions qui fonctionnent sur les deux types de bases de données, voir Bases de données multiples. Par exemple, au lieu d'utiliser string_agg() ou listagg() , pm_utils.string_agg() entraînera le même comportement pour les deux bases de données. Si pm_utils ne contient pas la fonction souhaitée, une instruction Jinja doit être créée pour s'assurer que la bonne fonction est appelée sur chaque base de données.

Concaténation de string

Pour combiner en chaînes, utilisez la fonction pm_utils.concat() . Cela produira les mêmes résultats pour SQL Server et Snowflake.
Exemple : pm_utils.concat("This is a nice string", null) = "This is a nice string" La concaténation de chaînes ne doit pas être effectuée avec des opérateurs tels que + ou || , car ils sont différents pour les deux bases de données (Snowflake utilise || et SQL Server utilise + ). De plus, la fonction standard concat() a un comportement différent sur les deux systèmes :

SQL Server

Snowflake

Les valeurs null seront ignorées et traitées comme une chaîne vide.
Les valeurs null donneront au résultat entier la valeur null .

Tri

Le tri est géré différemment dans Snowflake et dans SQL Server.

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

Valeurs nulles

SQL Server

Snowflake

null sera trié par défaut en premier (croissant)
null sera trié par défaut en dernier (croissant)

Handling capital letters

SQL Server

Snowflake

les majuscules sont triées comme prévu (AaBbCc)

trie d'abord par majuscules, puis par lettres non majuscules (ABCabc)

En tirets

Exemple : -Accountant-

SQL Server

Snowflake

les tirets sont ignorés dans le tri (de sorte que « -Accountant- » soit traité de la même manière que « Accountant »)

les tirets seront triés en haut

Gestion des espaces

Lorsque vous effectuez un regroupement par valeurs « A » et « A », cela est considéré comme une seule valeur dans SQL Server, mais comme deux valeurs différentes dans Snowflake. Par conséquent, le rognage est conseillé si vos données peuvent causer ce problème.

Sensible à la casse

Par défaut, SQL Server ne respecte pas la casse tandis que Snowflake est sensible à la casse. Cela signifie que Table."Field" = "Some_value" et Table."Field" = "SOME_VALUE" renverront le même ensemble de résultats dans SQL Server, mais potentiellement deux ensembles de résultats différents dans Snowflake.

Il est conseillé de modifier le comportement de votre base de données SQL Server locale pour qu'il corresponde au comportement de Snowflakes, afin d'éviter tout problème. Cela peut être accompli en définissant le classement de la base de données sur une valeur sensible à la casse.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Uipath Logo White
Confiance et sécurité
© 2005-2024 UiPath Tous droits réservés.