Vous êtes ici :
Considérations, consignes et limitations relatives à la migration SQL Data 360 (bêta)
Tenez compte des considérations, consignes et limitations ci-dessous lors de la migration de requêtes SQL personnalisées vers Data 360 SQL.
Considérations
- Data 360 SQL utilise la version Data 360 Direct SQL (HyperSQL) au lieu de la version TrinoSQL héritée.
- Le SQL hérité et le SQL Data 360 gèrent différemment les valeurs NULL. Le SQL hérité place toujours les valeurs NULL en dernier. Data 360 SQL utilise par défaut NULLS LAST pour les tris ascendants, mais change en NULLS FIRST pour les tris descendants.
- Data 360 SQL renvoie des dates en UTC en utilisant la notation offset (par exemple, +00:00), alors que SQL hérité utilise le suffixe Zulu (par exemple, Z).
- Data 360 SQL prend en charge les requêtes de données à haut volume et a amélioré Experience Page Time (EPT) par rapport au SQL hérité.
- Lorsque les valeurs de mesure sont identiques, SQL hérité et Data 360 SQL utilisent une logique de rupture d'égalité par défaut différente. De ce fait, les lignes apparaissent dans un ordre différent entre les deux systèmes pendant les scénarios de rupture d'égalité. Ce déplacement visuel de ligne est un comportement attendu et vous ne perdez aucune donnée.
- Data 360 SQL prend en charge la pagination dans les actifs Tableau de valeurs et gère efficacement les jeux de données volumineux en récupérant des données à la demande par défilement infini.
Consignes
- Sauvegardez votre fichier JSON ou XMD d'actif de tableau de bord avant de migrer un widget SQL personnalisé. Cette étape préserve vos règles de mise en forme conditionnelle.
- Pour vous assurer que vos requêtes fonctionnent correctement, placez tous les alias et identifiants de colonne entre guillemets doubles. Data 360 SQL est sensible à la casse et nécessite cette mise en forme pour correspondre exactement à vos données.
- Pour éviter la rupture de la mise en forme conditionnelle et maintenir une casse cohérente dans les requêtes de forme libre, utilisez des alias tels que SELECT Field_c AS "Field_c". Le SQL hérité et le SQL Data 360 préservent la casse définie par la requête lorsque vous utilisez un alias, même si l'alias n'est pas entre guillemets. Cependant, pour les champs non crénelés, Data 360 SQL restaure la casse de la source de données d'origine.
- Vérifiez vos requêtes pour des fonctions SQL héritées telles que TO_UNIXTIME et convertissez-les en équivalents SQL Data 360.
- Pour vous assurer que vos données restent précises, ajoutez explicitement NULLS LAST à vos requêtes ou vérifiez votre logique de tri. Data 360 SQL change l'ordre nul par défaut, ce qui entraîne des résultats inattendus dans vos tableaux et graphiques.
- Utilisez des alias uniques pour chaque champ afin d'éviter les problèmes de restitution des données dans l'interface utilisateur.
- Pour vous assurer que votre tableau de bord reste opérationnel, vérifiez que le facettage fonctionne correctement lorsque vous utilisez des filtres globaux dans des widgets SQL personnalisés. Le SQL imbriqué complexe entraîne souvent des problèmes de filtrage qui entraînent des données imprécises ou des visualisations rompues.
- Lorsque vous activez l'option « Désactiver le chargement paginé » dans un widget de tableau, la requête n'est pas immédiatement réexécutée. Le tableau ci-dessous montre encore les données tronquées de l'état paginé précédent. Pour charger toutes les lignes, enregistrez et rechargez le tableau de bord. Si le problème persiste, vérifiez que :
- L'étape est un type AGGREGATE hérité.
- Data SQL et les portes de pagination sont activés.
- Pour accéder à la syntaxe prise en charge et aux fonctions analytiques, cliquez sur l'icône Informations en regard de l'option SQL Data 360 dans l'éditeur SQL personnalisé.
Limitations
- Les couleurs et les styles disparaissent si la casse de clé ne correspond pas au format attendu. Ce problème se produit car Data 360 SQL conserve la casse d'origine des clés, alors que les mappages XMD hérités attendent généralement des clés minuscules.
- Data 360 SQL n'a pas d'équivalent direct pour certaines fonctions SQL héritées. Ce décalage rompt les formules de forme libre pendant la migration.
Cet article a-t-il résolu votre problème ?
Dites-nous ce que nous pouvons améliorer !
