Zweiter Schlüssel in der Tab. 37 "Sales Line", Performance

In der Tabelle 37 "Sales Line" gibt es ja den Schlüssel Nr. 2 "Document No.,Line No.,Document Type". Und ich habe ja ein einer meiner ersten Developer-Schulungen gelernt, dass dieser Schlüssel eigentlich optimaler als der erste Schlüssel (=Primärschlüssel) ist, wenn man alle Zeilen eines Beleges gefiltert nach der Belegart+Belegnr. sucht, denn in diesem Fall steht ja die Belegnr. ganz links, so dass die Selektivität deswegen optimaler ist. Nur wird dieser Schlüssel im NAV-Standard-Code nirgendwo verwendet. Warum eigentlich? Oder bringt es doch keine Performance-Vorteile, diesen Schlüssel in der Programmierung zu verwenden? Wie gesagt, die Frage betrifft nur die Fälle, wo wirklich die Belegzeilen nach der Belegart+Belegnr. ermittelt werden und es in der Kunden-DB 100-Tausende von Belegzeilen vorhanden sind.

Der Primärschlüssel ist "Document Type","Document No.","Line No."
Nach meiner Meinung auch kein schlechter um nach "Document Type" und "Document No." zu filtern.

Ich glaube nicht das "Document No.,Line No.,Document Type" wirklich spürbar performanter ist.
Könntest du ja eigentlich einmal mit großen Datensätzen testen und uns mitteilen.

Aber selbst wenn, dann ist der praktische Nutzen nicht so hoch, da bspw. die Aufträge nach dem Buchen in gebuchte Rechnungen/Lieferungen umgewandelt werden und diese dann auch verschwinden.
Oder gibt es hier jemanden der über 1 Million Datensätze in der Sales Line Tabelle hat?

mfg,
winfy

Ich glaube nicht das "Document No.,Line No.,Document Type" wirklich spürbar performanter ist.

Das kommt ganz darauf an.

Wenn du, wie jeder gute NAV- Anwender, deine ungebuchten Belege regelmäßig aufräumst, du also weniger als 100 ungebuchte Belege mit wenig Zeilen hast, dann hast du recht. Und es kommt darauf an, was du für Auswertungen und Selektionskriterien anwendest.

Lässt du aber deine Aufträge, z.B. für Auswertungen, stehen, dann macht es schon Sinn sich um den Primär- Schlüssel zu kümmern. Allerdings nur, wenn die Nummernserien gänzlich getrennte Nummernserien haben ("AN...","AB...","RE...",...).

Das geht in NAV eigentlich ganz einfach, indem du den SQL-Schlüssel des Primary- Keys änderst (Property "SQL-Index").

Der SQL- Server führt eine Statistik, wie "selektiv" ein Schlüssel ist. "Document Type" ist ein nicht gerade selektiver Schlüssel, Es gibt selbst bei 10000- Belegen nur max. 6 unterschiedliche Werte, die Belegnummern sind da schon besser. Im Zweifel wird er sich eher für einen Seek entscheiden, als für einen Zugriff über Schlüssel. Das heißt aber nicht unbedingt, das ein Schlüssel auf Offen in den Posten ein Schlechter Schlüssel ist, denn ein Filter auf Offen= true bringt i.d.R. nur sehr wenige Datensätze,selbst bei Millionen von Datensätzen, ist also sehr selektiv.

Gruß, Fiddi

Wenn du, wie jeder gute NAV- Anwender, deine ungebuchten Belege regelmäßig aufräumst, du also weniger als 100 ungebuchte Belege mit wenig Zeilen hast, dann hast du recht. Und es kommt darauf an, was du für Auswertungen und Selektionskriterien anwendest.

Lässt du aber deine Aufträge, z.B. für Auswertungen, stehen, dann macht es schon Sinn sich um den Primär- Schlüssel zu kümmern. Allerdings nur, wenn die Nummernserien gänzlich getrennte Nummernserien haben ("AN...","AB...","RE...",...).
Das geht in NAV eigentlich ganz einfach, indem du den SQL-Schlüssel des Primary- Keys änderst (Property "SQL-Index").
Gruß, Fiddi

Wie gesagt, genau diese Datenkonstellation haben wir bei einigen unserer Kunden, wo in der T.36+37 100-Tausende (bei einem sogar meherere Mio.!)
Einträge stehen, die meisten als kompl. erledigt (geliefert und fakturiert). Und die Kunden verwenden natürlich unterschiedlichen Nummernserien pro Belegart. Klar, NAV ist nicht für so etwas gedacht und man mus die Standard-Routinen zum Aufräumen nutzen (z.B. "Erl. Aufträge löschen+archivieren"). Nur lasssen unsere Kunden aus bestimmten Gründen die Belege doch in der T.36+37 stehen und wir können sie zum Aufräumen nicht zwingen. Hätte also die Verwendung des SETCURRENTKEY( "Document No.,Line No.,Document Type") zumindest in bestimmten Routinen denselben optimalen Effekt wie die Änderung des Property "SQL-Index" für den Primärschlüssel? Ich würde ungerne gleich was am Primärschlüssel ändern und würde zunächst mit dem SETCURRENTKEY( "Document No.,Line No.,Document Type") in meiner Programmierung versuchen.

Der Primärschlüssel der Tabelle 37 muss auf jeden Fall auf "Line No." enden, da ansonsten die AutoSplitKey-Funktion nicht mehr funktionieren würde.
Wie der SQL-Index zu dem Primärschlüssel aussehen soll/darf/kann, steht auf einem anderen Blatt

Der Primärschlüssel der Tabelle 37 muss auf jeden Fall auf "Line No." enden, da ansonsten die AutoSplitKey-Funktion nicht mehr funktionieren würde.

Hallo Timo, das habe ich nicht verstanden. Ich will doch nicht den Primäschlüssel ändern, ich will nur wissen ob die Verwendung (in der Programmierung) des zweiten Schlüssels aus der Schlüsselliste Performancevorteile bei der o.g. Datenkonstellation bringt. Es geht nicht um die Verwendung dieses Schlüssel in den Beleg-Subforms oder sonstiges.

Hi Jupiter,

laut deinen Beschreibungen gehe ich davon aus, dass die Verwendung des Keys ("Document No.,Line No.,Document Type") für spezifische Szenarien wirklich performanter ist.
Aber da kann man nur eins machen - ausprobieren. Ihr habt doch sicherlich ne Dev-DB von dem Kunden, der dort mehrere Mio-Datensätze stehen hat - probier es an der aus!
Sollte schon spürbar schneller sein.

Hallo Timo, das habe ich nicht verstanden. Ich will doch nicht den Primäschlüssel ändern, ich will nur wissen ob die Verwendung (in der Programmierung) des zweiten Schlüssels aus der Schlüsselliste Performancevorteile bei der o.g. Datenkonstellation bringt. Es geht nicht um die Verwendung dieses Schlüssel in den Beleg-Subforms oder sonstiges.

Am besten machst du KEIN SETCURRENTKEY wenn du es nicht für die Sortierung benötigst. Der SQL-Server nimmt sich schon selbst den am besten geeigneten Schlüssel (sofern die SQL- Statistiken regelmäßig gepflegt werden)

Gruß, Fiddi

Am besten machst du KEIN SETCURRENTKEY wenn du es nicht für die Sortierung benötigst. Der SQL-Server nimmt sich schon selbst den am besten geeigneten Schlüssel (sofern die SQL- Statistiken regelmäßig gepflegt werden)

Heißt es, dass wenn ich den SETCURRENTKEY absetze, dass ich dadurch auf dem SQL-Server die Verwendung der Statistiken für die aktuelle Abfrage unterdrücke und es es wäre suboptimal, obwohl der von mit im SETCURRENTKEY verwendete Schlüssel so ziemlich optimal aussieht?

Auf alle Fälle spart er sich den Sort auf das Ergebnis, wenn der SQL-Server dir die Daten zurück gibt. (Das kann bei einer Postentabelle schon ein wenig dauern)

Ein SETCURRENKEY, der bei einer bestimmten Abfrage mit bestimmten Filterkriterien optimal ist, kann bei einer anderen Abfrage mit andern Filterkriterien völlig daneben sein. Wenn du also nicht hundertprozentig sicher bist, wie gefiltert wird/wurde, lass den SETCURRENTKEY einfach weg, der SQL-Server sucht sich schon das nach seiner Meinung passende. Das macht übrigens auch der Standard immer öfter.

Gruß, Fiddi

Natürlich ist mir bekannt, dass man den SETCURRENTKEY's sinnvoll verwenden muss bzw. wann man diesen auch weglassen kann je nach dem auf welche Felder gefiltert wird. Ich wundere mich nur, dass der Standard irgend wann man diesen Key Nr.2 in der T. 37 (ebenso auch in der T.36 !) eingefügt hat (ab Version 5 oder so?) und dann wird dieser nirgendwo verwendet.