3. Februar 2007 20:04
Hallo!
Ich habe zwar keine Begründung dafür, aber ich habe mich bis dato immer davor gewährt neue Keys für eine Tabelle zu erstellen. Obwohl in den Dokus usw. auch vermerkt ist, dass man diese ganz einfach nur für das Sortieren anlegen kann.
Jetzt ist es leider doch so weit, ich brauche auf dem Sales Header eine bestimmte Sortierreihenfolge, bei der die Eindeutigkeit nicht gewahrt ist.
Zugesagtes Lieferdatum, Zugesagte Lieferzeit
Ist meine Angst begründet oder kann ich ohne Gefahr weitere Keys anlegen, ohne mir Sorgen zu machen.
Danke für alle Antworten im Voraus.
Zuletzt geändert von martinhaindl am 21. Februar 2007 20:42, insgesamt 1-mal geändert.
3. Februar 2007 20:11
Du brauchst dir keine großen Sorgen machen. Abgesehen von einem Update bei dem du ggf. die Schlüssel umsortieren musst (oder euer NSC) gibt es keinen Grund keine neuen Schlüssel anzulegen.
Wenn ihr mit dem SQL Server arbeitet, dann wird der eh für die Satzauswahl andere Schlüssel benutzen und im Fall einer Native Db sind Datumsfelder doch recht schnell soweit mir bekannt ist.
4. Februar 2007 00:24
Angst braucht man keine haben, sollte aber daran denken, dass jeder zusätzliche Schlüssel etwas Platz in der Datenbank kostet. Bei Stammdaten ist dies meist unkritisch, bei Postentabellen schlägt es aber langfristig schon zu Buche, besonders wenn auch noch Sumindex-Felder beim neuen Schlüssel dazukommen.
Zuletzt geändert von Kowa am 22. August 2007 16:48, insgesamt 1-mal geändert.
4. Februar 2007 12:17
Nun, Angst vor Keys ist unbegründet, aber man sollte Sie auch nicht bedenkenlos verwenden. KLar, Indexe brauchen Platz und die Erstellung bzw, Wartung kostet Rechenzeit, allerdings gibt es wie oben schon erwähnt, Unterschiede, je nachdem ob "native" oder SQL Server eingesetzt wird.
Native:
Keys/Indexes dienen zum Auffinden von Datensätzen, SIFT Management und festlegen der Sortierfolge.
Indexe können hier rel. großzügig angelegt werden, die Algorithmen mit denen der DB Server Abfragen bearbeitet, bzw. wie er dabei diese Indexe benutzt sind rel. performant.
SQL Server:
Indexe werden ausschließlich zum Auffinden von Datensätzen benutzt! SIFT wird "emuliert", die Sortierung wird z.B. dem SETCURRENTKEY entnommen. Welcher Index benutzt wird, entscheidet alleine der "Abfrageoptimierer" des SQL Servers; SETCURRENTKEY ist hier im Prinzip unerheblich (oft sogar eher störend).
Entscheidend ist hier, daß SQL Server genau gegensätzliche Erfordernisse an Indexe stellt als "native". Auf diese speziellen Erfordernisse kann ab 4.00 mit den neuen Key-Properties eingegangen werden; bei älteren Versionen muss man diese Änderungen SQL Server seitig einbauen.
Auch die Anzahl der Indexe ist entscheidend, hier ist weniger oft mehr. Werden z.B. NAV "Keys" nur zur Sortierung benutzt, dann kann u.U. darauf verzichtet werden, den entsprechenden Index auf SQL Server Seite zu erstellen (MaintainSQLIndex = FALSE), wenn bereits ein ähnlicher Index existiert.
Fazit:
Keys auf "native" sind rel. entspannt zu handhaben, mit SQL Server sollte man mit Bedacht vorgehen.