SQL: Zum Primärschlüssel oder nicht zum Primärschlüssel?

Question

ich eine Tabelle mit Sätzen von Einstellungen für Benutzer haben, hat es die folgenden Spalten:

UserID INT 
Set VARCHAR(50) 
Key VARCHAR(50) 
Value NVARCHAR(MAX) 
TimeStamp DATETIME 

UserID zusammen mit Set und Key sind einzigartig. So kann ein bestimmter Benutzer in einem bestimmten Satz von Einstellungen nicht zwei gleiche Schlüssel haben. Die Einstellungen werden von set abgerufen. Wenn also ein Benutzer einen bestimmten Schlüssel aus einem bestimmten Satz anfordert, wird der gesamte Satz heruntergeladen, so dass beim nächsten Mal, wenn ein Schlüssel aus demselben Satz benötigt wird, er nicht zur Datenbank gehen muss .

Sollte ich einen Primärschlüssel für alle drei Spalten (Benutzer-ID, Satz und Schlüssel) erstellen oder ein zusätzliches Feld erstellen, das einen Primärschlüssel hat (z. B. eine Autoincrement-Ganzzahl namens SettingID, schlechte Idee, ich denke), oder nicht einen Primärschlüssel erstellen und nur einen eindeutigen Index erstellen?

----- ----- UPDATE

nur Dinge zu klären: Dies ist ein Ende der Leitung Tabelle, ist es nicht in irgendeiner Weise verbunden sind. Benutzer-ID ist ein FK für die Tabelle Benutzer. Set ist kein FK. Es ist so ziemlich eine Hilfstabelle für meine GUI. Nur als ein Beispiel: Benutzer erhalten das erste Mal, dass sie Teile der Website besuchen, eine Hilfe Sprechblase, die sie schließen können, wenn sie wollen. Sobald sie es wegklicken, werde ich einige Einstellungen zum "GettingStarted" Set hinzufügen, das besagt, dass helpballoon X deaktiviert wurde. Wenn der Benutzer das nächste Mal auf dieselbe Seite kommt, wird in der Einstellung angegeben, dass die Hilfe-Sprechblase X nicht mehr angezeigt werden soll.

Answer 1

Sollte ich einen Primärschlüssel auf allen drei Säulen (userid, set, and key)

dieses machen.

Die Verwendung des Ersatz-Primärschlüssels führt zu einer zusätzlichen Spalte, die nicht für andere Zwecke verwendet wird.

ein UNIQUE INDEX Erstellen zusammen mit Surrogat Primärschlüssel ist gleich wie einen nicht gruppierten PRIMARY KEY zu schaffen, und wird in einem zusätzlichen KEY lookup führen, die schlimmer für die Leistung ist.

ein UNIQUE INDEX ohne PRIMARY KEY Erstellen in einer HEAP-organized Tabelle führt, die ein zusätzliches RID lookup muß die Werte für den Zugriff auf: auch nicht sehr gut.

Answer 2

Mit zusammengesetzten eindeutigen Schlüssel ist meist keine gute Idee.

Wenn Sie geschäftsrelevante Daten als Primärschlüssel haben, können Sie auch Probleme bekommen. Zum Beispiel, wenn Sie den Wert ändern müssen. Wenn es in der Anwendung nicht möglich ist, den Wert zu ändern, könnte dies in der Zukunft der Fall sein, oder er muss in einem Upgrade-Skript geändert werden.

Es ist am besten, einen Ersatzschlüssel zu erstellen, eine automatische Nummer, die keine geschäftliche Bedeutung hat.

bearbeiten nach dem Update:

In diesem Fall kann man sich denken konzeptionell keinen Primärschlüssel haben, und machen diese drei Spalten entweder den Primärschlüssel eines zusammengesetzten eindeutigen Schlüssel (es veränderbar machen).

Answer 3

Ich würde wahrscheinlich versuchen, sicherzustellen, dass UserID ein eindeutiger Bezeichner war, anstatt Duplikate von UserID im gesamten Code.Zusammengesetzte Schlüssel werden später im Code Ihres Codes verwirrend.

Ich nehme an, dies ist ein Nachschlagefeld für Konfigurationswerte irgendeiner Art, so dass Sie wahrscheinlich mit dem zusammengesetzten Schlüssel gehen könnten, wenn dies der Fall ist. Die Daten sind schon da. Sie können die Eindeutigkeit mit dem Primärschlüssel garantieren. Wenn Sie Ihre Meinung ändern und später entscheiden, dass dies nicht für Sie geeignet ist, können Sie ganz einfach eine SettingId hinzufügen und den ursprünglichen zusammengesetzten Schlüssel zu einem eindeutigen Index machen.

Answer 4

Erstellen Sie einen separaten Primärschlüssel. Unabhängig davon, wie sich die Geschäftslogik ändert, welche neuen Regeln müssen auf Ihr Feld Key VARCHAR (50) angewendet werden - wenn Sie einen Primärschlüssel haben, werden Sie völlig unabhängig von der Geschäftslogik.

Answer 5

Meiner Erfahrung nach kommt es darauf an, wie viele Tabellen diese Tabelle als FK-Information verwenden. Willst du 3 zusätzliche Spalten in deinen anderen Tabellen, nur um einen FK zu tragen?

Persönlich würde ich eine andere FK-Spalte erstellen und eine eindeutige Einschränkung über die anderen drei Spalten legen. Dies macht Fremdschlüssel zu diesem Tisch viel einfacher zu schlucken.

Answer 6

Bessere Benutzer-ID als 32-Bit-newid() oder eindeutige Kennung, da UserID als int einen Hinweis für den Benutzer der wahrscheinlichen UserID gibt. Dies löst auch das Problem des zusammengesetzten Schlüssels.

Answer 7

Wie viele Tasten und Sets haben Sie? Müssen diese Varchar (50) sein oder können sie auf eine Nachschlagetabelle zeigen? Wenn Sie Set und Key in SetId und KeyId konvertieren können, können Sie Ihren Primärschlüssel für die 3 ganzzahligen Werte erstellen, die viel schneller sind.

Answer 8

Ich bin kein Befürworter von zusammengesetzten Schlüsseln, aber in diesem Fall als ein Ende der Linientabelle könnte es sinnvoll sein. Wenn Sie jedoch Nullen in einem dieser drei Felder zulassen, weil einer oder mehrere der Werte zum Zeitpunkt des Einfügens nicht bekannt sind, kann es Schwierigkeiten geben und ein eindeutiger Index ist möglicherweise besser.