Primärschlüssel als Komposit nur für Primärtabelle

In unserer Umgebung befindet sich eine Tabelle. Kürzlich wurde festgestellt, dass die Performance durch die Sortierung von datetime, die die dba zum Primärschlüssel machen wollte, stark verbessert wurde. Da er mit der Datetime keine Eindeutigkeit garantieren kann, fügte er die ID, die einmal der Primärschlüssel war, in seinen neuen zusammengesetzten Schlüssel ein.Primärschlüssel als Komposit nur für Primärtabelle

Also gibt es eine Tabelle mit dem Primärschlüssel als datetime/id und auch der Clustered Index ist auf diese Weise definiert. Alle pk/fk-Beziehungen sind immer noch richtig eingerichtet und existieren auf dem ID-zu-ID-Paradigma, das man erwarten würde.

Was könnte das mögliche Problem eines einseitigen Primärschlüssels sein?

Und die Leistung wird mit dieser Änderung erheblich verbessert.

In dem Schema ist der eigentliche "Primärschlüssel" jedoch zwei Spalten. was könnte möglicherweise falsch laufen?

Quelle

2016-08-09 discosammy

Mögliche Duplikate von [Warum mehrere Spalten als Primärschlüssel (zusammengesetzter Primärschlüssel) verwenden] (http://stackoverflow.com/questions/2626158/why-use-multiple-columns-as-primary-keys-composite-primary -Schlüssel) – Whencesoever

Das hat also die bestehenden FK-Beziehungen nicht gebrochen. Warum hat er nicht einfach einen nicht gruppierten Index auf die Datetime gesetzt? – Paparazzi

Behalten Sie die vorhandene eindeutige Spalte als Primärschlüssel bei. Erstellen Sie dann einen neuen INDEX in der Datetime-Spalte. Sie erwähnen nicht Datenbank-Plattform, aber wenn dies Sql Server 2008 (* ich glaube *) oder später Sie können dann wählen Sie INCLUDE-Spalten, die mit den indizierten Spalten beibehalten werden. Dies sollte Ihnen immer noch nahe an der Geschwindigkeit sein, mit der das Datum in den Clustered-Index aufgenommen werden soll. Wenn Sie weitere Optionen wünschen, sollten Sie die Datenbankplattform und -version einbeziehen. – Igor

Tun Sie das nicht! Richten Sie einen eindeutigen Index mit den beiden Feldern ein. Es muss kein Primärschlüssel sein. In der Tat, wenn Sie wollen, dass der ursprüngliche Schlüssel einzigartig bleibt, dann ist das eine schreckliche Idee.

Quelle

2016-08-09 17:58:11 HLGEM

Ich sehe nicht, wie das Hinzufügen eines Datums zu einer eindeutigen ID die Eindeutigkeit gefährden würde. –

@Joe: Wenn der alte PK nur auf der ID-Spalte basiert. Aber jetzt ist der neue PK als 'id' + 'date'-Spalten definiert. Die ID-Spalte erlaubt jetzt doppelte Werte. Dies ist wahrscheinlich nicht wünschenswert. – sstan

Ah, ohne einen eindeutigen Index für ID könnte ID dann dupliziert werden. Ich dachte, es wäre impliziert, dass ID + Datum nicht eindeutig wäre. Ich habe es falsch verstanden. –

EDIT: Diese Antwort wurde Sql Server angenommen. Wenn es sich herausstellt, dass es nicht ist, werde ich meine Antwort löschen.

Sie nicht Details auflisten, so muss ich eine sehr allgemeine Antwort geben. In meiner Forschung habe ich herausgefunden, dass die meisten einen kurzen Primärschlüssel/Clustered-Index empfehlen.

Der wahre Schlüssel hier ist jedoch, was Sie mit erhöhter Leistung meinen. Ist es nur eine Frage? Mit anderen Worten, hat diese Änderung einen positiven oder zumindest nicht signifikanten Leistungseinfluss auf alle Operationen dieser Daten? Benutzeroberflächen, alle Berichte und so weiter. Oder raubte dieser Peter Paul?

Wenn es sich um eine Berichtsdatenbank oder ein Data Warehouse handelt, bei dem die meisten Berichte auf dem Datum basieren, könnte ich sehen, warum Benutzer empfehlen, den Clustered-Index so einzurichten, dass alle Berichte von Nutzen sind Einsen. In jeder anderen Situation kann ich mir vorstellen, dass ein nicht geclusterter Index fast die gleiche Stufe oder Leistungssteigerung bietet, ohne die Größe der PK zu erhöhen, die in allen Nachschlagevorgängen (mehr Bytes lesen = langsamere Leistung) als verwendet wird Sie benötigen mehr Speicherplatz auf Ihren Datenseiten.

EDIT: Dieser Artikel erklärt dieses Thema besser als ich konnte.

https://www.simple-talk.com/sql/learn-sql-server/effective-clustered-indexes/

Quelle

2016-08-09 18:06:23

Sind wir sicher, dass OP SQL Server verwendet? – sstan

Guter Punkt, ich dachte, ich würde nur Sql Server Fragen durchsuchen. –

Der Leistungsvorteil Sie derzeit sehen sind (wenn echte) ist aufgrund des Clustered-Index mit dem Primärschlüssel zugeordnet ist, und nicht der Primärschlüssel selbst. Wenn Sie mit dem aktuellen Index zufrieden sind, sich aber über die Eindeutigkeit Gedanken machen, sollten Sie die eindeutige datetime/id als Clustered-Index beibehalten, aber zu Ihrer alten eindeutigen ID als Primärschlüssel zurückkehren.

Dies löst auch das Problem, dass andere Tabellen, die diesen Primärschlüssel referenzieren, die Erstellung einer wahrscheinlich unpassenden Datetime-Spalte erfordert haben, um eine Fremdschlüsselbeziehung zu erstellen.

Quelle

2016-08-09 19:22:40

genau ... der Clustered-Index-Teil, den ich nicht in Frage stelle. das ist in diesem Fall eindeutig vorteilhaft. Ich weiß nicht, warum er den Clustered-Index nicht erstellt und den Primärschlüssel in Ruhe gelassen hat. Er sieht eine Leistungssteigerung. Es ist messbar durch das, was er getan hat. Die Joins sind da, weil alle Ids gleich sind. Das gleiche gilt für die fk-Einschränkungen (die nur auf die ID verweisen). Der einzige Unterschied besteht darin, dass die Datumsspalte in der Tabellendefinition enthalten ist. – discosammy

Primärschlüssel als Komposit nur für Primärtabelle

Antwort

Verwandte Themen