Gibt es einen Vorteil eines Primärschlüssels, der alle Spalten der Tabelle umfasst?

Ich habe eine Tabelle mit vier Spalten, die alle nicht nullwertfähig sind, und die Daten sind so, dass alle vier benötigt werden, um einen eindeutigen Datensatz zu unterscheiden. Das heißt, wenn ich einen Primärschlüssel machen würde, müsste er alle Spalten umfassen. Abfragen gegen die Tabelle werden fast immer einen einzelnen Datensatz zurückziehen, dh alle Spalten werden in der Abfrage gefiltert.

Da jede Spalte durchsucht werden muss, nützt mir ein Primärschlüssel überhaupt (abgesehen von der Durchsetzung der Eindeutigkeit von Datensätzen)?

In Ihrem Fall sind diese Felder ein natürlicher Schlüssel.

Ersatzschlüssel:

Ersatzschlüssel sind Schlüssel, die keine geschäftliche Bedeutung haben und ausschließlich zur Identifizierung eines Datensatzes in der Tabelle verwendet werden. Solche Schlüssel sind entweder datenbankgenerierte Werte (Beispiel: Identität in SQL Server, Sequenz in Oracle, Sequenz / Identität in DB2 UDB usw.) oder systemgenerierte Werte (wie sie über eine Tabelle im Schema generiert werden).

Natürlicher Schlüssel:

Schlüssel sind natürlich, wenn das Attribut, das sie darstellen, zur Identifizierung unabhängig vom Datenbankschema verwendet wird. Dies bedeutet im Grunde genommen, dass die Schlüssel natürlich sind, wenn sie beispielsweise von Menschen verwendet werden: Rechnungsnummern, Steuer-IDs, SSN usw.

Ersatzschlüssel gegen natürliche Schlüssel für Primärschlüssel

Ich bevorzuge das Hinzufügen eines Ersatzschlüssels, um die Verwaltung von Geschäfts- und Datenbankmodellen zu trennen. Eine andere Frage ist die Verwendung von gruppiertem und nicht gruppiertem Index für Primärschlüssel. Wenn Sie eine Tabelle ändern (nicht statische Tabelle, die hochintensive Einfügungen oder Aktualisierungen enthält), treten bei Verwendung von gruppiertem Index für nicht monoton erhöhten Schlüssel Probleme mit der Leistung auf.

Es wird normalerweise empfohlen, in solchen Situationen einen Ersatzschlüssel zu haben, also Fremdschlüssel in anderen Tabellen (und in allen extern gespeicherten Datensatzreferenzen, z. B. wenn sie in Abfragezeichenfolgen enthalten sind, auf die sich eine http (s) -Anforderung bezieht der Datensätze) haben etwas zu verweisen, das sich nicht ändert, wenn sich die Daten in der Zeile ändern. Wenn Sie dies tun, ist dies Ihr Primärschlüssel.

Wenn Sie keinen solchen Ersatzschlüssel hinzufügen, ist es kein Nachteil, wenn Sie angeben, wie Sie die Daten beschreiben, auf die zugegriffen wird, wenn alle vier Spalten als Primärschlüssel vorhanden sind. Wenn Sie den Schlüssel zum Clustered-Index für die Tabelle machen, werden solche Anforderungen unterstützt, da es eine Ebene im B-Tree auf der Festplatte gibt, um die Daten für eine bestimmte Zeile zu finden.

Bei Verbundschlüsseln als Primärschlüssel treten auch Probleme mit der Indexgröße auf, die sich auf die Datenträgernutzung, die Geschwindigkeit und die Sicherung auswirken können. Sie können Kimberly Tripps Beiträge zu Primärschlüsseln und Clustered-Indizes hier überprüfen: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Auch ich würde in diesem Fall einen Ersatzschlüssel anstelle eines natürlichen Schlüssels vorschlagen.

Wenn Sie eine Tabelle haben, die eine Viele-zu-Viele-Beziehung mit nur zwei Spalten darstellt, erscheint dies vernünftig.

Vgl. diese SO Frage

Aber ich gebe zu, dass ich auch in diesen Fällen Ersatzschlüssel hinzufüge.