breadcrumbDescription
Overvejelser, retningslinjer og begrænsninger for Data 360 SQL-migrering (beta)
Husk på disse overvejelser, retningslinjer og begrænsninger, når du migrerer tilpassede SQL-forespørgsler til Data 360 SQL.
Overvejelser
- Data 360 SQL bruger Data 360 Direct SQL-versionen (HyperSQL) i stedet for den ældre TrinoSQL-version.
- Forældet SQL og Data 360 SQL håndterer NULL-værdier forskelligt. Forældet SQL placerer altid NULL-værdier sidst. Data 360 SQL skifter som standard til NULLS LAST for stigende sorter, men ændres til NULLS FIRST for faldende sorter.
- Data 360 SQL returnerer datoer i UTC ved brug af forskydningsnotation (f.eks. +00:00), mens ældre SQL bruger zulu-suffikset (f.eks. Z).
- Data 360 SQL understøtter højvolumen dataforespørgsler og har forbedret EPT (Experience Page Time) sammenlignet med den ældre SQL.
- Når målværdier er identiske, bruger ældre SQL og Data 360 SQL forskellig standardbindingslogik. På grund af dette vises rækker i en anden rækkefølge mellem de to systemer under relationsscenarier. Denne visuelle rækkevagt er forventet adfærd, og du mister ikke nogen data.
- Data 360 SQL understøtter sideinddeling i værditabelaktiver og håndterer effektivt store datasæt ved at hente data efter behov gennem uendelig rulning.
Retningslinjer
- Sikkerhedskopier din dashboard JSON eller aktiv-XMD-fil, før du migrerer en tilpasset SQL-widget. Dette trin bevarer dine betingede formateringsregler.
- Hvis du vil sikre, at dine forespørgsler fungerer korrekt, skal du indsætte alle kolonnealiasser og identifikatorer i dobbelte anførselstegn. Der skelnes mellem store og små bogstaver i Data 360 SQL og kræver, at denne formatering matcher dine data nøjagtigt.
- Hvis du vil forhindre brudt betinget formatering og vedligeholde ensartet versalfølsomhed i Freeform-forespørgsler, skal du bruge aliaser som SELECT Field_c AS "Field_c". Både forældet SQL og Data 360 SQL bevarer forespørgselsdefineret versalfølsomhed, når du bruger et alias, selvom aliasset ikke er i anførselstegn. Men for ikke-aliaterede felter vender Data 360 SQL tilbage til den oprindelige datakildesituation.
- Gennemse dine forespørgsler for ældre SQL-funktioner, f.eks. TO_UNIXTIME, og konverter dem til Data 360 SQL-ækvivalenter.
- Hvis du vil sikre, at dine data forbliver nøjagtige, skal du eksplicit føje NULLS LAST til dine forespørgsler eller bekræfte din sorteringslogik. Data 360 SQL ændrer standardrækkefølgen nul, hvilket medfører uventede resultater i dine tabeller og diagrammer.
- Brug entydige aliaser for hvert felt for at forhindre problemer med gengivelse af data i brugergrænsefladen.
- Hvis du vil sikre, at dit dashboard forbliver funktionelt, skal du bekræfte, at facettering fungerer korrekt, når du bruger globale filtre på tilpassede SQL-widgets. Kompleks indlejret SQL forårsager ofte filtreringsproblemer, der fører til unøjagtige data eller brudte visualiseringer.
- Når du aktiverer indstillingen "Inaktiver sideindlæsning" på en tabelwidget, køres forespørgslen ikke straks igen. Tabellen viser stadig afkortede data fra den tidligere sideinddelte tilstand. Hvis du vil indlæse alle rækker, skal du gemme og genindlæse dashboardet. Hvis problemet fortsætter, skal du bekræfte, at:
- Trinnet er en forældet AGGREGAT-type.
- Data SQL og sideinddelingsgatefiler er aktiveret.
- Hvis du ønsker adgang til understøttede syntaks- og analysefunktioner, skal du klikke på ikonet Oplysninger ud for indstillingen Data 360 SQL i den tilpassede SQL-editor.
Begrænsninger
- Farver og typografier forsvinder, hvis nøglens versalfølsomhed ikke matcher det forventede format. Dette problem forekommer, fordi Data 360 SQL bevarer den oprindelige versalfølsomhed af nøgler, mens ældre XMD-tilknytninger typisk forventer små bogstaver.
- Data 360 SQL mangler direkte ækvivalenter for nogle ældre SQL-funktioner. Denne uoverensstemmelse afbryder formler i frit format under migrering.
Løste denne artikel dit problem?
Giv os besked, så vi kan forbedre os!
