[gelöst] SETCURRENTKEY: Beschleunigter Zugr. auf SQL-Server?

Hallo Allerseits,

und ein frohes, neues Jahr!


Ich möchte über ein Feld mit SETRANGE auf die Tabelle Item zugreifen. Auf diesem Feld liegt ein Key/Index, es ist aber halt nicht der Primary Key "Code".

Die Sortierung ist mir eigentlich schnuppe, ich muß nur ggf. Mehrfachtreffer im Loop abarbeiten.

Datenbank ist SQL.

Ist es für einen schnellen Datenzugriff sinnvoll, mit SETCURRENTKEY den Index vorher auszuwählen? Oder wählt der SQL-Server seinen Index selbst und das SETCURRENTKEY dient ausschließlich der Sortierung - und macht damit den Zugriff sogar langsamer?

(Habe zwar die Suchfunktion des Forums bemüht, aber mit meinen Suchbegriffen zum Setcurrentkey alles und nix gefunden; darum die explizite Anfrage )

Viele Grüße,

SF

Zuletzt geändert von SafetyFirst am 12. Januar 2010 11:52, insgesamt 1-mal geändert.

SetCurrentKey steht nur im order by. Den Rest macht der Sql-Server schon richtig.

Hi!

Leider ist es mittlerweile nicht mehr ganz so einfach ...
Der SQL Server wählt zwar i.d.R. den Index für eine Abfrage autark, aber die Sortierung (und damit SETCURRENTKEY) beeinflusst diese Entscheidung je nach verwendetem SQL Cursor Typ ...
Liegen Filter und Sortierung zu weit auseinander, dann kann dies zu Index Scans etc. kommen, die die Performance (deutlich) vermindern ...
Ob und welcher SETCURRENTKEY also gebraucht wird, hängt vom individuellen Kontext ab.

Mehr zu Indexen: http://dynamicsuser.net/blogs/stryk/archive/2009/11/26/technical-airlift-2009-munich-nav-sql-performance-optimization-indexes.aspx
In Kürze wird dazu auch ein "NAV/SQL Quickie" (#2: Curse of the Cursor) auf DynamicsWorld.com dazu veröffentlicht: http://msdynamicsworld.com/author/j-rg-stryk

Gruß,
Jörg

Hallo,

vielen Dank für die Erläuterungen. Dies erhöht schon mein Verständnis.

Ich setze denn mal das "Gelöst"-Tag, aber bin natürlich dankbar, wenn es weitere Tipps und Erläuterungen gibt.

Viele Grüße,

SF

Also quasi die "Faustregel" könnte lauten:
Wenn man einen "Key" setzt, der die meisten/wichtigsten Felder des "Filters" enthält, dann macht man nix verkehrt ...

OK. Ich liebe Faustregeln.

Hier aber auch nochmal eine Rückfrage zum Verständnis: Das setzen des Keys ändern ja die Sortier-Reihenfolge des Recordsets, so wie ich es verstanden habe, indem ein ORDER BY im SQL-Statement abgesetzt wird. Bedeutet dies nicht für den Server wiederum einen (zeitaufwändigen) Sortier-Prozess? Oder ist es hier so, daß aufgrund der möglicherweise induzierten clevereren Index-Wahl der Zeitverlust bzgl der Sortierung kompensoert wird?

Viele Grüße,

SF

Also NAV sendet immer ein ORDER BY - entweder anhand des SETCURRENTKEY (o.ä.); andernfalls wir Primärschlüssel-Sortierung verwendet.

Ein Problem besteht immer dann, wenn die gewünschte Sortierung (ORDER BY) zu sehr von der Index-Sortierung abweicht. Der Index wiederum hängt vom Filter ab (WHERE) und tw. von der Sortierung (Curosr-Steuerung) ... hört sich kompliziert an, ist es auch ...
D.h. man muss also dafür sorgen das Filter, Index und Sortierung nicht zu unterschiedlich sind; auch das ist leicht gesagt, aber oft nicht so einfach umsetzbar:
Man wählt ja eine bestimmte Sortieung (SETCURRENTKEY) nicht ohne Grund, und wer sagt denn, dass genau auf diese Felder auch gefiltert wird?
Was für eine bestimmte Abfrage optimal ist, lässt sich pauschal nicht so einfach voraussagen - "es hängt davon ab" ...

OK, das hilft mir weiter.

Vielen Dank für Deine Erklärungen!

Frohes Schaffen,

SF