Frage zu Tabellen-Design, Key ohne SQL
12. November 2009 09:52
Hallo, mal eine frage zu Keys, die keinen SQL-Maintain haben
ich habe die Tabelle 32 Item ledger Entry mit einigen Millionen Datensätzen.
nun bräuchte ich einen einzigen Report, der Gruppen bilden soll aus einem Feld, das in keinem Key enthalten ist.
nun will ich nur deswegen die tabelle nicht mit einem weiteren Key belasten und kam auf die Idee, dass ich einen Key anlege, er aber nicht als SQL-Key ge"Maintained" ist. dann kann ich den Report so gruppieren wie ich will, und habe keinen zusätzlichen Verwaltungsaufwand für den zusätzlichen Key.
nun die frage: holt sich der SQL-Server bei ausführung des Reports den nach seiner statistik günstigsten Key, den er wirklich hat, oder geht der dann stur nach primary key vor?
ich habe die Tabelle 32 Item ledger Entry mit einigen Millionen Datensätzen.
nun bräuchte ich einen einzigen Report, der Gruppen bilden soll aus einem Feld, das in keinem Key enthalten ist.
nun will ich nur deswegen die tabelle nicht mit einem weiteren Key belasten und kam auf die Idee, dass ich einen Key anlege, er aber nicht als SQL-Key ge"Maintained" ist. dann kann ich den Report so gruppieren wie ich will, und habe keinen zusätzlichen Verwaltungsaufwand für den zusätzlichen Key.
nun die frage: holt sich der SQL-Server bei ausführung des Reports den nach seiner statistik günstigsten Key, den er wirklich hat, oder geht der dann stur nach primary key vor?
Re: Frage zu Tabellen-Design, Key ohne SQL
12. November 2009 10:59
Zugegeben, ich bin kein SQL-Profi (man möge mich alo korrigieren wenn ich falsch liege*danke*)
Lt. dem was ich bisher gelesen habe, versucht der SQL-Server selbst den günstigsten Key zu ermitteln.
Maintain Sql-Idex, gibt an den Sql-Server die Anweisung (beim Kompilieren der Tabelle) einen zusätzlichen Index zu erstellen, der von dem Key selbst abweichen darf (sollte aber mit bedacht geschehen!).
Zum Aufsummieren der Felder wird das Propertie "Maintain SWIFT-Index" genommen, der SQL-Server legt dann einen sparaten Index mit den einzelnen Buckets an (dadurch kann schnell summiert werden), jedoch besteht beim Speichern ein höhrerer Schreibaufwand.
Wenn das Propertie nicht gesetzt ist, muß der Server auf "althergebrachte" Weise die Daten Filtern und einzeln aufsummieren.
Das kann bei kleinen Tabellen praktikabel sein, bei großen Postentabellen allerdings kann das einen entsprechend hohen Leseaufwand bedeuten.
Daher so wie ich das (nach meinem Kenntnisstand inrterpretiere), wird beim anlegen eines neuen Keys, auch immer ein Index auf dem Server angelegt. In deinem Fall würde der zusätzliche Index jedoch entfallen.
Und ja, wie eingangs beschrieben, versucht der Server selbst den geegneten Key zu finden.
(Hoffentlich habe ich jetzt kein "Gefährliches Halbwissen" hier geschrieben)
Lt. dem was ich bisher gelesen habe, versucht der SQL-Server selbst den günstigsten Key zu ermitteln.
Maintain Sql-Idex, gibt an den Sql-Server die Anweisung (beim Kompilieren der Tabelle) einen zusätzlichen Index zu erstellen, der von dem Key selbst abweichen darf (sollte aber mit bedacht geschehen!).
Zum Aufsummieren der Felder wird das Propertie "Maintain SWIFT-Index" genommen, der SQL-Server legt dann einen sparaten Index mit den einzelnen Buckets an (dadurch kann schnell summiert werden), jedoch besteht beim Speichern ein höhrerer Schreibaufwand.
Wenn das Propertie nicht gesetzt ist, muß der Server auf "althergebrachte" Weise die Daten Filtern und einzeln aufsummieren.
Das kann bei kleinen Tabellen praktikabel sein, bei großen Postentabellen allerdings kann das einen entsprechend hohen Leseaufwand bedeuten.
Daher so wie ich das (nach meinem Kenntnisstand inrterpretiere), wird beim anlegen eines neuen Keys, auch immer ein Index auf dem Server angelegt. In deinem Fall würde der zusätzliche Index jedoch entfallen.
Und ja, wie eingangs beschrieben, versucht der Server selbst den geegneten Key zu finden.
(Hoffentlich habe ich jetzt kein "Gefährliches Halbwissen" hier geschrieben)
Re: Frage zu Tabellen-Design, Key ohne SQL
12. November 2009 12:21
hmm, danke. werds mal ausprobieren.