MSSQL 2005 - Zusammengesetzter Primärschlüssel - Vorteile/Nachteile bei Anwendung

[Unknowen]

Hallo Forum,

ich habe eine Datenbank mit relativ vielen Benutzern und einem hohen Aufkommen von Datensätzen in einer Tabelle. Wegen diesen stetig ansteigenden Datensätzen möchte ich den Primärschlüssel dieser Tabelle auf zwei Spalten "erweitern".

Auf Grund der hohen Benutzerzahl will ich das nicht ohne Weiteres einfach so umsetzen. Über die Vor- und Nachteile bezüglich Geschwindigkeit und Umständlichkeit habe ich mich bereits informiert. Diese dürften in meinem Fall allerdings nicht viel ausmachen, da diese Tabelle die "grundlegendste" Tabelle ist und auf diesen Primärschlüssel nicht zugegriffen wird.

Meine Frage: Gibt es durch zusammengesetzte Primärschlüssel irgendwelche Unterschiede (Vorteile/Nachteile) im laufenden Betrieb der Datenbank? Muss ich mit eventuellen Problemen rechnen? (Wenn ja, welche?) Was muss ich sosnt noch beachten?

Ich hoffe, mir kann da jemand weiter helfen. Vielen Dank schon mal für jede Antwort.

[dr.dimitri]

Wieso verwendest nicht einfach eine vortlaufende Nummer? MSSQL bietet ja auch sowas wie auto increment an.

Soviele Billionen User wirst du schon nicht bekommen das der wertebereich überläuft.

Vor einen PK, der aus fachlichen Feldern besteht (egal ob zusammengesetzt oder nicht) kann ich nur abraten.

Dim

[Unknowen]

Ich verwende ja eine fortlaufende Nummer. Hier zu erklären, warum diese Tabelle so groß ist, würde wohl den Rahmen sprengen - wäre recht kompliziert. Fakt ist, dass der Primärschlüssel in naher Zukunft den Int-Wert 2.147.483.647 übersteigt. Deshalb wird eine Vergrößerung des Primärschlüssels nötig.

Der PK besteht nur aus Zahlen und enthält im Prinzip keine Informationen (ist nur zur Einmaligkeit der Datensätze nötig).

[dr.dimitri]

Naja dann ändere ihn in einen BIGINT das geht von -9223372036854775808 bis 9223372036854775807

Damit erweiterst den Wertebereich nochmal leicht

Dim

[Unknowen]

Kann das nicht einfach zu einem BIGINT umändern, weil es sonst Probleme mit der Software selbst gibt.

Will das ja im Prinzip auch gar nicht umändern, würde nur gerne wissen, welche Folgen ein zusammengesetzter Primärschlüssel im laufenden Betrieb haben kann.

[dr.dimitri]

Im laufenden Betrieb? Naja rein technisch gesehen wird der zugehörige Index ein bissl größer und es ist eben ein klein bissl auwändiger den PK zu validieren - in der Praxis aber meist unerheblich.

Die SQLs müssen natürlich angepasst werden, da der Zugriff auf nur eine Spalte ggf. kein eindeutiges Ergebnis mehr bringt.

Tabellenm, die den ursprünglichen PK referenzieren müssen natürlich auch entsprechend angepasst werden. Ebenso die SQLs die diese untergeordneten Tabellen befüllen. Ich würde das sehr gründlich testen bevor Du das in einer produktiven Umgebung mal so eben änderst.

Dim

Bearbeitet 12. August 2008 von dr.dimitri

[SoL_Psycho]

Nach Möglichkeit würde ich auch eher versuchen, den jetzigen Index zu nem BigInt zu ändern und ggbnfalls die Software selbst anzupassen.

Zusammengesetzte Primärschlüssel kannst du zwar auch nutzen, aber aus Erfahrung weiß ich, dass man da doch ab und an ins Straucheln kommen kann... Also wenn du das auf nen zusammengesetzten Schlüssel änderst, dann teste wirklich alles mögliche durch, weil es doch recht "einfach" zu Problemen kommen kann

[Unknowen]

Im laufenden Betrieb? Naja rein technisch gesehen wird der zugehörige Index ein bissl größer und es ist eben ein klein bissl auwändiger den PK zu validieren - in der Praxis aber meist unerheblich.

Die SQLs müssen natürlich angepasst werden, da der Zugriff auf nur eine Spalte ggf. kein eindeutiges Ergebnis mehr bringt.

Tabellenm, die den ursprünglichen PK referenzieren müssen natürlich auch entsprechend angepasst werden. Ebenso die SQLs die diese untergeordneten Tabellen befüllen. Ich würde das sehr gründlich testen bevor Du das in einer produktiven Umgebung mal so eben änderst.

Was muss ich da testen? :confused: - sorry, da kenn ich mich wohl zu wenig mit aus...

Andere Tabellen greifen ja nicht auf den zusammengesetzten Primärschlüssel zu.

Nach Möglichkeit würde ich auch eher versuchen, den jetzigen Index zu nem BigInt zu ändern und ggbnfalls die Software selbst anzupassen.

Funktioniert leider nicht, da dieser Wert nicht so recht mit Classic ASP funktionieren will, wenn ich mit RecordSets arbeite. (dafür verwende ich bald ein Formular, um eventuell Datensätze dieser Tabelle zu löschen)

Zusammengesetzte Primärschlüssel kannst du zwar auch nutzen, aber aus Erfahrung weiß ich, dass man da doch ab und an ins Straucheln kommen kann...

Was genau heißt das jetzt für mich?

Im Moment würde ich ja noch nicht auf diesen zusammengesetzten Primärschlüssel zugreifen. Das erfolgt dann nur über das oben angesprochene Formular. Sonst greife ich immer über andere Spalten der Tabelle auf die Daten zu.

[dr.dimitri]

Was muss ich da testen?

Ganz einfach. Du baust Dir eine Testumgebung, führtst deine Änderung aus und prüfst ob alles noch so funktioniert wie es sollte.

Andere Tabellen greifen ja nicht auf den zusammengesetzten Primärschlüssel zu.

Also wenn es keine FKs gibt, die diesen PK referenzieren und es auch keine SQLs gibt, die den PK verwenden, dann sollte das gehen - rein theoretisch.

Dim