McClane hat geschrieben:Vor allem kann der SQL-Server einen miesen oder gar fehlenden Schlüssel durch einen schlauen ersetzen.
Das ist so nicht ganz richtig; dieses weit verbreitete Mis(t)verständnis resultiert IMHO daraus, dass in nativem C/SIDE der Begriff "Key" und "Index" nicht wirklich unterschieden wird.
Definitionsgemäß ist ein "
Key" ein CONSTRAINT - also eine "Einschränkung" oder auch "Regel". z.B. ist beim "Primary Key" die Einschränkung/Regel, dass jeder Wert eindeutig sein muss.
Alle anderen "Keys" in NAV - neben dem PK - sind eigentlich keine "Keys" sondern "
Indexe": eine interne Hilfstruktur zum Auffinden von Datensätzen.
Während in C/SIDE Key & Index zu einem "Ding" vermischt wird, so wird in SQL schon deutlich unterschieden!
Am "Key" ändert der SQL Server gar nix - niemals nicht. Der in NAV definierte "Key" - per SETCURRENTKEY, Property, etc., egal ob voll- oder teilqualifiziert - bestimmt lediglich die Sortierung bei einer Abfrage, also die ORDER BY Clause. Wird kein "Key" explizit gesetzt, dann wird der PK verwendet.
Wenn es nun um das "Auffinden der DS" geht, dann wählt sich SQL Server den passenden "
Index" dazu autark! Dazu wird in erster Linie der gesetzte Filter betrachtet (WHERE Cause) und erst in zweiter Priorität wird auf die Sortierung eingegangen; dennoch sollten "Key" (Sortierung) und "Index" (Filter) nicht zu unterschiedlich sein, da dies sonst Performance-Probleme heraufbeschwören kann.
Mittels "Index Hinting" kann man die SQL Server Index-Selektion übersteuern; d.h. man kann den zu verwendenden Index vorgeben - hier muss man genau wissen, was man macht, ansonsten erzeugt man eher Probleme.
Zu beachten ist dabei auch folgendes:
Je nach "Patch-Level" (also der NAV Build Nummer) werden für Result-Sets entweder "
Fast Forward Cursor" (FFC) oder "
Dynamic Cursor" (DC) verwendet.
FFC optimieren für den Filter (WHERE), DC für die Sortierung (ORDER BY). D.h. mit DC kann es mitunter zu erheblichen Problemen kommen - aber wie gesagt, aktuelle Updates stellen (wieder) um auf FFC.
Ein Beispiel dazu:
SELECT * FROM "G_L Entry" WHERE
"G_L Account No_" = '12345' ORDER BY "Entry No_"
EIn FFC würde den Index "$1" ziehen (gehört zum "Key"
"G/L Account No.", "Posting Date"), wegen "G/L Account No.". Der Plan wäre dann ein schneller "Index Seek".
Ein DC würde "...$0" ziehen (PK "Entry No."). Da dieser Index keinerlei Info zu "G/L Account No." enthält, bleibt nix anderes übrig als ein lahmer "Index Scan" ...
Schönes Wochenende,
Jörg