Du är här:
Överväganden, riktlinjer och begränsningar för Data 360 SQL-migrering (beta)
Tänk på dessa saker, riktlinjer och begränsningar när du migrerar egna SQL-frågor till Data 360 SQL.
Att tänka på
- Data 360 SQL använder Data 360 Direct SQL-versionen (HyperSQL) istället för den äldre TrinoSQL-versionen.
- Äldre SQL och Data 360 SQL hanterar NULL-värden olika. Äldre SQL placerar alltid NULL-värden sist. Data 360 SQL blir som standard NULLS LAST för stigande sortering men ändras till NULLS FIRST för fallande sortering.
- Data 360 SQL returnerar datum i UTC med offsetnotation (till exempel +00:00), medan äldre SQL använder suffixet Zulu (till exempel Z).
- Data 360 SQL har stöd för datafrågor med hög volym och har förbättrad upplevelsesidtid (EPT) jämfört med äldre SQL.
- När måttvärden är identiska använder äldre SQL och Data 360 SQL olika standardlogik för att bryta band. På grund av detta visas rader i olika ordning mellan de två systemen under scenarier för att bryta kopplingar. Detta visuella radskift är förväntat beteende och du förlorar inga data.
- Data 360 SQL har stöd för paginering i värdetabelltillgångar och hanterar effektivt stora datauppsättningar genom att hämta data på begäran genom oändlig bläddring.
Riktlinjer
- Säkerhetskopiera din instrumentpanels JSON- eller tillgångs-XMD-fil innan du migrerar en egen SQL-widget. Detta steg bevarar dina regler för villkorlig formatering.
- För att säkerställa att dina sökfrågor fungerar korrekt, omge alla kolumnalias och identifierare med dubbla citattecken. Data 360 SQL är skiftlägeskänsligt och kräver denna formatering för att exakt matcha dina data.
- För att förhindra bruten villkorlig formatering och upprätthålla enhetliga skiftläge i friformfrågor, använd alias som SELECT Field_c AS "Field_c". Både Legacy SQL och Data 360 SQL bevarar sökfrågedefinierat skiftläge när du använder ett alias, även om aliaset inte citeras. För fält utan alias går Data 360 SQL dock tillbaka till det ursprungliga datakällans skiftläge.
- Gå igenom dina sökfrågor för äldre SQL-funktioner som TO_UNIXTIME och konvertera dem till motsvarande Data 360 SQL.
- För att säkerställa att dina data förblir korrekta, lägg uttryckligen till NULLS LAST i dina sökfrågor eller bekräfta din sorteringslogik. Data 360 SQL ändrar standard nullordningen, vilket orsakar oväntade resultat i dina tabeller och diagram.
- Använd unika alias för varje fält för att förhindra problem med dataåtergivning i användargränssnittet.
- För att säkerställa att din instrumentpanel förblir funktionell, kontrollera att aspekter fungerar korrekt när du använder globala filter på egna SQL-widgetar. Komplex kapslad SQL orsakar ofta filtreringsproblem som leder till felaktiga data eller trasiga visualiseringar.
- När du aktiverar alternativet "Inaktivera paginerad inläsning" i en tabellwidget körs inte sökfrågan direkt igen. Tabellen visar fortfarande avkortade data från det tidigare paginerade läget. För att läsa in alla rader, spara och läs in instrumentpanelen igen. Om problemet fortsätter, kontrollera att:
- Steget är av äldre AGGREGATE-typ.
- Data SQL och pagineringsgrindar är aktiverade.
- För att komma till syntax- och analysfunktioner som stöds, klicka på Info-ikonen bredvid alternativet Data 360 SQL i den egna SQL-redigeraren.
Begränsningar
- Färger och stilar försvinner om nyckelskiftläge inte matchar det förväntade formatet. Detta problem uppstår eftersom Data 360 SQL bevarar nycklarnas ursprungliga skiftläge, medan äldre XMD-mappningar vanligtvis förväntar sig gemena nycklar.
- Data 360 SQL saknar direkta motsvarigheter för vissa äldre SQL-funktioner. Denna felmatchning bryter fria formler under migreringen.
Löste denna artikel ditt problem?
Berätta för oss vad vi kan förbättra!
