Sortieralgorithmus von NAV

Ich mache zur Zeit ein paar Übungen zum Verständniss von NAV mit Hilfe von impuls Unterlagen.

Eine aktuelle Aufgabe an der ich gerade sitze ist, wie man eine Artikelkartei erstellt und eine zugehörige Artikelposten Anzeige.

Dabei muss man einen Menü Button "Artikel" anlegen mit "Posten" als Unterbutton (oder was wäre der Fachbegriff dafür?!) - die Properties davon sind der Knackpunkt ( siehe Anhang )

Man kann also NAV nach etwas sortieren lassen das KEIN Primary key ist, das ist mir soweit relativ klar dass das geht. ABER : Was mich interessiert, welchen Sortieralgorithmus benutzt NAV``? Bubblesort, Qucksort? Das wäre schon sehr interessant und in dem Fall sogar relevant zu wissen ob Navision eher sehr lange zum Sortieren braucht oder ob es in der Lage ist, recht schnell zu sortieren.

edit: und noch eine Frage : Hat es einen speziellen Grund, dass an der Stelle NAV auf der Form Item Ledger Entries und nicht direkt auf der Tabelle Item Ledger Entry arbeitet? (Property RunObjekt)

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von dayscott am 19. März 2009 18:19, insgesamt 1-mal geändert.

Nav kann nur Sortierungen von festgelegten Schlüsseln anzeigen. Und die müssen nicht extra sortiert werden ;) Die dürften als Pointer irgendwo auf der Platte liegen.

Oder meinst du, welchen Sortieralgorhytmus Nav beim Erstellen der Schlüssel benutzt, wenn eine DB-Sicherung eingelesen wird? Keine Ahnung, aber ist ja auch uninteressant.

Nun, auch wenn der Hersteller das nirgendwo offiziel publik macht, so arbeitet der native C/SIDE Server nach ISAM (Index Sequential Access Method); siehe dazu http://en.wikipedia.org/wiki/Isam

Deshalb kann der Server Daten nur sortieren, wenn dafür ein entsprechender Index - in NAV sprich "Key" - vorhanden ist, dieser Index wird dann sequentiell gelesen, die Datensätze werden in der Reihenfolge dann ausgegeben. Deshalb ist es in NAV (native) auch wichtig wenn immer möglich nur auf Felder zu filtern, die im Index enthalten sind, und das noch in der Reihenfolge des "Keys", ansonsten geht's mit der Performance "begrab" ...

Im Falle von SIFT (Sum Index FlowField Technology) funzt das ganze ein wenig cleverer, hier können mit Hilfe eines "Summen Indexes" beliebige Summen mit quasi 3 Zugriffen/Operationen aus dem Index ermittelt werden; siehe http://de.wikipedia.org/wiki/SumIndex_Field_Technology#SIFT_Technologie

Das gilt aber wie gesagt nur für den nativen Server; SQL Server könnte da schon ganz anders vorgehen, die Notwendigkeit einen "Key" für die Sortierung anzugeben ist nur historisch begründet (auch SIFT wird hier - bedauerlicherweise - anders gehandhabt).

Und was das "RunObject" angeht: man sollte NIEMALS direkt Tabellen aufrufen, sondern immer nur Forms zur Anzeige von Daten verwenden! Würde man die Tabelle öffnen, so könnte man bestimmte Eigenschaften nur kaum beeinflussen (Sichtbarkeit, Editierbarkeit, etc.) so dass man unerwünschte Änderungen riskieren würde ...
In "Forms" kann man eben definieren, was angezeigt werden soll und in wie weit der Zugriff auf Daten gestattet ist.

Schöne Grüße,
Jörg

wenn NAV nur nach Keys sortieren kann wieso wird (RunFormView) auf Item No. sortiert? (das ist KEIN Key in der entsprechenden Tabelle)

Stimmt: Wenn ein Schlüssel mit dem Feld beginnt, geht´s auch, sorry.

Genau. In dem Fall wird der erste "Key" gezogen, der mit dem genannten Feld (oder den Feldern) beginnt. D.h. ein "Key" muss in NAV nicht immer "voll qualifiziert" angegeben werden. Siehe dazu auch "C/SIDE Reference Guide" zu SETKURRENTKEY.

Deshalb kann der Server Daten nur sortieren, wenn dafür ein entsprechender Index - in NAV sprich "Key" - vorhanden ist, dieser Index wird dann sequentiell gelesen,

und dieser wurde dann logischerweise irgendwann vorher sortiert. Dh Datensätze liegen bei mir in erster Linie geordnet nach dem Primary Key rum und in zweiter Linie geordnet nach jedem vorhandenem Key (auch wenn die Werte der Keys, auser dem Primary Key, nicht eindeutig sein müssen)

Deshalb ist es in NAV (native) auch wichtig wenn immer möglich nur auf Felder zu filtern, die im Index enthalten sind, und das noch in der Reihenfolge des "Keys", ansonsten geht's mit der Performance "begrab" ...

wie filter ich den in einer bestimmten Reihenfolge?, das ist mir bis dato noch gar nicht untergekommen.
Weder beim statischen FIlter noch beim dynamischen (?) - damit mein ich den Filter, den der User nutzt - Filter

DAs mit "filtern in Reihenfolge" ist so gemeint:

Wird z.B. ein "Key" (nicht PK) verwendet, der so aufgebaut ist ...

"Item Category Code", "Product Group", "Description"

... dann sollte man auch in dieser Folge ggf. Filter setzen ...

SETRANGE("Item Category Code", ...)
SETRANGE("Product Group", ...)
SETRANGE("Description", ...)

... die Filter dann beim sequentiellen Lesen des Indexes optimal angewendet werden. Wird in einer anderen Reihenfolge gefiltert, dann muss der Index u.U. mehrmals durchgearbeitet werden und das kostet dann Zeit. Wird auf Felder gefiltert, die nicht im aktuell verwendetetn Index enthalten sind, dann ist ebenfalls zusätzlicher Aufwand zum filtern erforderlich. Ob tatsächlich ein spürbares Performance Problem auftritt, hängt im wesentlichen von der Datenmenge ab auf die zugeriffen werden soll.

Ich muss an dieser Stelle einräumen, dass ich dem C/SIDE Server inzwischen etwas "fern" bin deshalb weiss ich nicht ob jüngere NAV Versionen inzwischen schlauer sind, was den Umgang mit Schlüsseln und Filtern angeht ...

[McClane]

Da wir grad beim Thema sind: wie verhält sich das eigentlich beim SQL-Server? ich habe da schon drei Meinungen gelesen.
1: Man soll die Reihenfolge der Filter genauso beachten wie oben bei Native beschrieben
2: Man soll die Reihenfolge der Filter so setzen, dass vorne möglichst schon die meisten Datensätze weg gefiltert werden
3: völlig egal, der SQL-Server macht das schon richtig

Zuletzt geändert von McClane am 24. März 2009 03:01, insgesamt 1-mal geändert.

Da wir grad beim Thema sind: wie verhält sich das eigentlich beim SQL-Server? ich habe da schon drei Meinungen gelesen.
1: Man soll die Reihenfolge der Server genauso beachten wie oben wie Native beschrieben
2: Man soll die Reihenfolge der Filter so setzen, dass vorne möglichst schon die meisten Datensätze weg gefiltert werden
3: völlig egal, der SQL-Server macht das schon richtig

Mit SQL Server: Die Reihenfolge in der gefiltert wird ist völlig unerheblich. ALLE Filter - also Eigenschaften, programmierete Filter und Benutzer-Filter etc. - werden in EINER einzigen WHERE Clause zusammengefasst (deshalb sehen die tw. auch so "fies" aus ). Die Reihenfolge der Felder innerhalb der WHERE Clause ist unerheblich, SQL Server gewichtet die einzelnen Filter nach ihren Operatoren (also nach =, <, >, <>, like, etc.).
Dann wird primär anhand der Filter über "Index Statistiken" ein optimaler (?) "Index" zum schnellstmöglichen ermitteln der Ergebnismenge gewählt. I.d.R. wird es sich dabei um einen "Non Clustered Index" handeln; wurden die DS anhand dieses NCI gefunden (hier allerdings nur die Indexwerte), dann wird über einen "Bookmark Lookup" auf den "Clustered Index" zugegriffen, der dann die vollständigen DS enthält.

Es ist also wichtig, dass der optimale Index für eine Abfrage schnell gefunden und genutzt werden kann. D.h. auch, dass SQL Server immer versucht, so wenig wie möglich Daten zu lesen; deshalb sind Indexe mit hoch selektiven Feldern (also mit "vielen unterschiedlichen Werten") wichtig - die Anforderung ist damit exakt Gegenteilig zur ISAM Anforderung: so z.B. sind Optionsfelder wie "Document Type" am Anfang eines ISAM-Indexes hervorragen, für SQL Server kann sowas zum Problem werden.

Der in NAV gewählte "Key" Kontext - also z.B. via SETCURRENTKEY, wnn nicht explizit angegeben, dann wird der PK verwendet - spielt hier leider noch eine Rolle: dieser "Key" wird immer als ORDER BY Clause angegeben, bestimmt also die Reihenfolge der DS im Ergebnis.

Ist der Unterschied zwischen dieser gewünschten Sortierung und der tatsächlichen Index Sortierung zu groß, dann können Probleme entstehen:

A) SQL Server nimmt den optimaleren Index, muss die Daten für die Ausgabe dann aber zeitaufwendig umsortieren
B) SQL Server nimmt einen weniger optimalen Index, der aber näher an der gewünschten Sortiereung drn ist

In beiden Fällen wird dann die Verarbeitung eben länger dauern.

Man sollte in der NAV Entwicklung - für SQL Server, gilt aber auch für C/SIDE - darauf achten, dass die Diskrepanz zwischen Filter, Key und Index nicht zu groß ist. Oder auch anders gesagt: wenn die Sortierung nicht wichtig ist, dann lieber den SETCURRENTKEY weglassen (dann wird PK Sortierung votrgegeben), bevor eine schlechte/wiedersprüchliche Sortierung verwendet wird. Das vrewenden der PK Sortierung ist i.d.R. fast immer unproblematisch, da ja der "Clustered Index" auf dem PK basiert.

Ich sollte also meine SetRanges/SetFilters möglichst genau und auf so viele Felder wie möglich setzen, kann aber die "alten (native-)" SetCurrentKeys davor mehr oder weniger in die Tonne treten, da der SQL-Server das selbst entscheidet - richtig? Und wenn ja - macht es überhaupt noch Sinn, Schlüssel anzulegen, außer wenn man sie für eine bestimmte Sortierung in einer Ansicht braucht?

Und noch eine Verständnisfrage: kommt es bei Tabellen-Zugriffen aus CSide überhaupt jemals zu einem Join?

Und vielen Dank schonmal für die obige ausführliche Antwort :)

Es macht schon Sinn für bestimmte Abfragen "Keys" anzulegen, da ja diese im SQL Server zu entsprechenden Indexen werden. Filtert man also auf Felder die nirgendwo in einem Key/Index vorhanden sind, dann muss sich der SQL Server die DS i.d.R. aus dem "Clustered Index" - üblicherweise via "Scan" - herausholen; und "Index Scans" sind teuer (hoher I/O, hohe CPU Last, hoher RAM Verbrauch).
Den SETCURRENTKEY sollte man eben nur verwenden, wenn die Sortierung wichtig ist, ansonsten macht der SQL Server das schon alleine richtig.

Und was den JOIN angeht: Nein. No. Niet. Niente. Non.
NAV kann nur stumpfe SELECT auf eine Tabelle. Operationen wie JOIN etc. erfordern eine echte relationale Datenbank; da NAV aber ISAM Wurzeln hat, ist die gesammte Applikation auf sequentielle Zugriffe ausgerichtet - also: Filter setzen, Schleife, Filter setzen, Schleife, usw. ...

Ich persönlich hoffe ja sehr, dass sich das irgendwann einmal ändern wird - sobald die native Büchse endlich tot ist (harrr, harrr, ...) - dann könnte man in der Programmierung so EINIGES verbessern ... heute braucht man tw. in C/AL eine DIN A4 Seite Code um das zu ermitteln, was man in SQL mit einem 5-Zeiler hinbringt ...

Aber sind denn mehrfache Joins aus großen Datenmengen nicht auch mit sehr hoher Last verbunden? Ab einer gewissen Datenmenge soll doch die Datenredundanz wieder positiv für die Performance sein, wenn dadurch Joins vermieden werden.

wie stehen denn die Chancen, dass so eine Revolution von Microsoft ausgehen wird ?! Ich meine wenn man die Performanz verbessern würde, würde sich NAV automatisch auch für größere Firmen eignen und nicht nur für mittelständische Unternehmen (jetzt mal im Großen Rahmen gedacht)

Aber sind denn mehrfache Joins aus großen Datenmengen nicht auch mit sehr hoher Last verbunden? Ab einer gewissen Datenmenge soll doch die Datenredundanz wieder positiv für die Performance sein, wenn dadurch Joins vermieden werden.

Ja, das mit Redundanz vs. Normalisierung ist immer ein Thema mit Datenbanken, also OLAP vs. OLTP - hat alles sein für und wieder; ich denke das hängt letztlich vom Einzelfall ab, was besser ist.

JOINS hätten eben den Vorteil, dass die einzelen Teilabfragen mit mehreren parallelen CPU Threads abgearbeitet werden könnten; d.h. es könnten mehere CPU in die Operation eingebunden werden, die damit schneller verarbeitet wird. Das setzt natürlich voraus, dass entsprechenden Systemresourcen - CPU - vorhanden sind. Aber SQL Server ist ja genau auf solche Verarbeitungen ausgelegt - im Gegensatzt zum C/SIDE Server der alles "single threaded" abspult.
IMHO wäre es wünschenswert in NAV zumindest die Möglichkeit für JOINS o.ä. zu haben ...

IMHO wäre es wünschenswert in NAV zumindest die Möglichkeit für JOINS o.ä. zu haben ...

Stimmt natürlich. Das könnte einem viel Tipparbeit sparen.

Danke nochmal :)

wie stehen denn die Chancen, dass so eine Revolution von Microsoft ausgehen wird ?! Ich meine wenn man die Performanz verbessern würde, würde sich NAV automatisch auch für größere Firmen eignen und nicht nur für mittelständische Unternehmen (jetzt mal im Großen Rahmen gedacht)

Also letztes Jahr auf der "Directions EMEA 2008" hat sich MS nur vage zu dem Thema geäußert (leider alles "non-disclosed"). Im April ist es ja wieder so weit - "Directions EMEA 2009" - vielleicht gibt es da ja schon konkretere Ausblicke ...

Aber das Problem ist eben folgendes:
Würde man es richtig machen wollen, dann müsste man NAV komplett soz. von "innen nach aussen drehen" um die Applikation vollständig SQL Server tauglich zu machen und damit auch höheren Anforderungen gerecht werden kann. Auch müsste man die C/AL Sprache erheblich ändern/erweitern. Was danach allerdings übrig bleibt, wird nix mit dem NAV zu tun haben wie wir es kennen.
Würde man so rigoros das System ändern, so wäre dies ein ERHEBLICHER Aufwand und mit sehr hohen Kosten verbunden. Kommt das Problem des "Upgrades" hinzu, also wie man NAV Bestandskunden einfach, schnell und kostenverträglich migriert. Ähnliches gilt für die Add-On Entwicklungen der NAV Partner. Hier muss der Investitionsschutz für Kunden und Partner an erster Stelle stehen!

Es bleibt also nix anderes übrig, als sich in kleinen stetigen Schritten dem "Optimum" zu nähern; d.h. das System konsequent zu verbessern, neue/bessere Technologien zu integrieren, etc. aber dabei immer auch die bestehenden Kunden und Partner "mitzunehmen" ... Ich denke das MS auch dieser Philosophie folgt.