|
Title: Performance Profit-Change-Key m.b.t. omnummeren Artikel in LORI Post by: Heart Informatisering B.V. on July 15, 2016, 01:50:12 pm M.i.v. deze Releasenote is er een nieuwe index bijgekomen op de tabel LORI (Ingekomen Faktuurregels).
De enige reden voor opname van de index (op Bedrijf + Artikelnummer) is de performance van de module Profit-Change-Key. Middels de module Profit-Change-Key is het mogelijk om Sleutels om te nummeren. Om niet meteen te technisch te worden, zie een Sleutel maar als alle Identifikaties die we kunnen Raadplegen-/Toevoegen-/Wijzigen-/Verwijderen. In praktijk zijn er twee soorten Sleutels die 99,9% van alle Sleutelwijzigingsopdrachten dekken: Artikelen en Relaties. Van een op te geven sleutelveld (LOAR_AID voor Artikelen, of LORE_RID voor een Relatie-Identifikatie) kunnen we de oude- en de gewenste nieuwe waarde opgeven. Profit-Change-Key doorloopt daarna de hele database op zoek naar de oude sleutelwaarden en nummert ze om naar de nieuwe. Per te onderzoeken tabel gaat Profit daarbij op zoek naar de meest optimaal bruikbare index. Mocht er geen bruikbare index gevonden worden, dan zal de tabel Sequentieel moeten worden doorlopen; d.w.z. record voor record. De benodigde tijd voor het omnummeren zal veel meer tijd vergen als alle records stuk voor stuk doorlopen (en gekontroleerd) moeten worden dan als we de om te nummeren gegevens via een index kunnen vinden (in welk geval we geen records teveel hoeven te lezen). In principe geldt dat Profit-Change-Key "as-is" is. Het betreft een algemeen mechanisme wat in de basis gebruikt kan worden om "een sleutel" om te nummeren, maar wat zelf helemaal niets afweet van "Artikelnummer" of "Relatie-Id". In theorie zouden we net zo goed een Transportmiddel-type kunnen willen omnummeren, waarbij het logisch zal zijn dat we niet op alle plekken waar zo'n veld gebruikt wordt we ook meteen een index op zo'n veld hebben. Zo'n index gaan we er ook niet zo maar even bij maken. Echter, omdat "Artikelen" een van de meest voorkomende soort Sleutelwijzigingen betreft, en deze tabel zeer veel records kan bevatten, is er nu toch een index opgenomen om het omnummeringsproces aanzienlijk te versnellen. Stel dat we 1.000 Artikelen moeten omnummeren en een tabel heeft 1.000.000 records, dan zullen we 1.000.000.000 records moeten lezen. Met index hoeven we niet per sleutelwijziging meer het hele bestand door en kunnen we direkt zien dat ons om te nummeren Artikel misschien niet eens voorkomt in de tabel.
|