Ik merk dat de Exact Online-connectie erg traag is.
Ik heb relatief kleine hoeveelheden data.
select Division as 'Company'
, Supplier as 'Vendor'
, SupplierName as 'Name'
, DivisionName
, AmountDC
, year(EntryDate)
from ExactOnlineREST#PurchaseEntry.PurchaseEntries as p
inner
join ExactOnlineREST#CRM.Accounts
on
De gebruikte tabellen zijn gebaseerd op relatief trage API’s (circa 60 rijen per seconde sustained throughput).
limitAls het gaat om zo snel mogelijk voorbeelddata te krijgen, voeg dan een limit 100 toe. Die zal niet altijd helpen omdat er een join betrokken is die mogelijk niet leidt tot verbeteringen vanwege het gebruik van een hasj join.
De join-strategie van Invantive UniversalSQL kan gewijzigd worden (documentatie).
In plaats van alle gegevens van twee gerelateerde tabellen op te halen en te koppelen, wordt een van beide tabellen gebruikt als uitgangspunt en worden voor alle bijbehorende waardes uit de andere tabel queries afgevuurd. Dit gedrag wordt gehanteerd tot een bepaald maximum aantal waardes, die standaard op 5.000 staan. Daarboven wordt een full join gemaakt tussen beide tabellen.
In het geval van bijvoorbeeld OData gebeurt dat met een of meerdere queries, telkens met een beperkt aantal waardes.
Hash-joins die alles ophalen vooraleer te joinen kunnen volledig uitgeschakeld worden voor een join met de no_join_set hint of beperkt qua aantal met een join_set hint.
Voorlopig is het advies om een no_join_set te hanteren mits het datavolume van de tabellen niet extreem groot is met bijvoorbeeld:
select /*+ no_join_set(p, 10000) */
1 c
...
where filterDaarnaast is het verstandig om filters toe te voegen zodat er een kleinere dataset gebruikt wordt. Dit kan door een where toe te voegen aan het einde op de (bij voorkeur) eerste tabel zoals:
where p.status = 10 /* Reduceert volume met x% */
of door gebruik te maken van een inner view zoals:
from ( select * from PurchaseEntries where ... ) p
join ...
Merk op dat bij Exact Online specifiek niet alle tabellen op dezelfde velden een filter zullen doorgeven aan de API-server. Op andere platformen is dat weer anders. De mogelijkheid is op te vragen via het zoeken op de eigenschap “server side filtering” in SystemTableColumns@DataDictionary. De SQL-engine gebruikt deze informatie. Exact verwijdert helaas over de jaren gaandeweg steeds meer mogelijkheden tot server side filtering om hun moverende redenen.
Van de meeste tabellen op Exact Online met potentieel veel transactiedata kennen varianten die specifiek er op gericht zijn om met enkele API-calls miljoenen rijen te kunnen ophalen. Dit zijn de zogenaamde *Incremental-tabellen. Deze incremental-tabellen zijn grofweg net zo snel voor 1 rij als voor alle rijen en daarom meestal niet geschikt voor OLTP-toepassingen.
Zie voor meer informatie:
Tenslotte kan in restgevallen overwogen worden om te kiezen voor het maken van een kopie, bijvoorbeeld in de in-memory storage, lokaal of in een traditionele database.