|
Title: Performance Gefaktureerd Verkoopoverzicht ADS/SQL Post by: Heart Informatisering B.V. on November 21, 2018, 11:02:15 am In de ADS versie van Profit hebben we de mogelijkheid om bijv. een Gefaktureerd Verkoopoverzicht op te vragen op basis van een versie die haar data (zoveel mogelijk) bepaalt o.b.v. SQL Opdrachten.
De performance van deze SQL Statistiek hangt mede af van de gebruikte Selektieniveau's, en wordt daarnaast ook beïnvloed door talloze J/N rubrieken die in de loop der tijd voor diverse klanten zijn ontwikkeld. Stel dat we enkel de omzet in een periode willen zien op Debiteurniveau, dan kunnen we volstaan met een SELECT statement die sumt in de LOFR tabel, JOIN't met de LOUF tabel t.b.v. de selektie op Periode. De Faktuurdebiteur staat ook die in LOUF tabel, dus, e.e.a. Query leidt direkt tot een resultatentabel met daarin enkel per Debiteuren een totaal. Is het Selektieniveau echter geen "Debiteur" maar "Chargenummer", dan zal per Faktuurregel eerst moeten worden uitgezocht welke Raaplijsten er op die Faktuur zijn gefaktureerd, en welke Charges er vervolgens op die Raaplijsten zijn geleverd. Dit betreft dan een veel complexere Query, maar tevens een met meerdere (en veel grotere) tabellen. Toch ook kunnen we dingen doen die er voor zorgen dat een standaard overzicht op bijv. Debiteur trager wordt; immers, vink maar eens rubriek 'Gewichten weergeven' aan, en de statistiek moet ineens weten welke produkten er gefaktureerd zijn, in welke verschijningsvorm die geleverd zijn, dat de geleverde 20 liter eigenlijk 36 Kg betrof, en dat de Emballageset die aan de Verschijningsvorm hangt een leeg blik en een deksel bevat, die tesamen ook nog 0,8 Kg per Verschijning wogen. Dergelijke berekeningen zijn soms dermate complex dat ze zich niet laten ombouwen naar een SQL Query, en zo toch, deze Query dermate complex maken dat die niet optimaal meer performt. Bij dit soort situaties zal de SQL Query een grotere resultatentabel opvragen, welke bijv. geacht Artikel-/Verschijning is, om vervolgens naderhand per Artikel-/Verschijning uit deze resultatentabel op zoek te gaan naar de aanvullende data. Niet alleen wordt het overzicht trager omdat we een te grote resultatentabel terug krijgen, ook het achteraf uitzoeken van de ontbrekende informatie kost extra tijd. In het geval dat we een Gefaktureerd Verkoopoverzicht opstartte, en de uitkomst rapporteerden in de eenheid 'Liters', dan werd er ook een resultatentabel teruggevraagd per Artikel, om daarna per Artikel het Soortelijk Gewicht te bepalen t.b.v. de omrekening naar Liters. Met ingang van deze Releasenote let deze statistiek er bewuster op in welk geval ze wél een Artikel moet opzoeken, en wanneer dat niet nodig is. Bedenk dat we een resultaat van 70.000 records terugkrijgen, waarvan misschien 90% al in Liters gefaktureerd is. Voor al die situaties hoeven we dus niet eerst een Artikel te lokaliseren om te weten hoeveel liters er gefaktureerd zijn. Door dit soort kontroles zal het tellertje wat de 70.000 resultaten doorloopt een behoorlijk stuk sneller lopen, immers, ze hoeft per resultaat niet altijd veel uit te zoeken. Gebruikt u bepaalde data op de print niet, filter er dan ook niet op, het kan de performance van het overzicht ten goede komen! M.a.w. woorden, daar waar we Liters, Kilogrammen, maar ook Stuks verkopen kon het wel eens onzin zijn dit altijd 'in liters' of 'kilogram' weer te geven; rapporteer in eenheid '*' en het overzicht zal al sneller zijn.
|