Database Design Primay Schlüssel, ID vs String

Question

Ich plane derzeit, eine Musik-Streaming-Anwendung zu entwickeln. Und ich frage mich, was wäre besser als Primärschlüssel in meinen Tabellen auf dem Server. Eine ID int oder eine eindeutige Zeichenfolge.

Methoden 1:

Songs Tabelle: songID (int), Titel (string), * Artist ** (string), Länge (int), * Album ** (string

)

Genre Tabelle Genre (string), Name (string)

SongGenre: *** songID **** (int), Ge *** NRE **** (string)

Methode 2

Songs Tabelle: songID (int), Titel (string), * ArtistID ** (int), Länge (int) * ALBUMID ** (int)

Genre Table GenreID (int), Name (string)

SongGenre: *** songID **** (int), *** GenreID **** (int)

Key: Bold = Primärschlüssel, * Feld ** = Foreign Key

Ich bin derzeit der Gestaltung Methode unter Verwendung von 2, wie ich es glauben wird die Lookup-Performance beschleunigen und weniger Platz verbrauchen, da ein Int viel weniger Platz benötigt als ein String.

Gibt es einen Grund, warum das keine gute Idee ist? Gibt es etwas, auf das ich achten sollte?

Answer 1

Sie tun das Richtige - Identity-Feld sollte numerisch und nicht string-basiert sein, sowohl aus Platzgründen als auch aus Performance-Gründen (passende Schlüssel auf Strings sind langsamer als Übereinstimmungen bei ganzen Zahlen).

Answer 2

MSSQL können diese IDs für Sie generiert, wenn ein int mit

Answer 3

Meine Empfehlung ist (IDENTITY Stichwort sehen) verwenden ids.

Sie können das "Genre" mit 20000 Songs umbenennen, ohne etwas zu brechen.

Die Idee dahinter ist, dass die ID die Zeile in der Tabelle identifiziert. Was auch immer die Reihe hat, ist etwas, das in diesem Problem nicht wichtig ist.

Answer 4

Dies ist zu einem großen Teil eine Frage der persönlichen Präferenz.

Meine persönliche Meinung und Praxis ist, immer Integer-Schlüssel zu verwenden und immer Ersatzzeichen anstelle von natürlichen Schlüsseln zu verwenden (also niemals so etwas wie Sozialversicherungsnummer oder den Genre-Namen direkt verwenden).

Es gibt Fälle, in denen ein Auto-Nummernfeld nicht geeignet oder nicht skalierbar ist.In diesen Fällen kann es sinnvoll sein, eine GUID zu verwenden, die eine Zeichenfolge in Datenbanken sein kann, die keinen systemeigenen Datentyp dafür haben.

Answer 5

Gibt es einen Grund, warum das keine gute Idee ist? Gibt es etwas, auf das ich achten sollte?

Ja. Ganzzahlige IDs sind sehr schlecht, wenn Sie die gleichen Daten außerhalb einer einzelnen Datenbank eindeutig identifizieren müssen. Zum Beispiel, wenn Sie die gleichen Daten in ein anderes Datenbanksystem mit möglicherweise bereits existierenden Daten kopieren müssen oder Sie eine verteilte Datenbank haben. Das Wichtigste ist, dass eine Ganzzahl wie 7481 außerhalb dieser einen Datenbank keine Bedeutung hat. Wenn Sie später diese Datenbank vergrößern müssen, ist dies möglicherweise nicht möglich, ohne Ihre Daten chirurgisch zu entfernen.

Die andere Sache zu beachten ist, dass Ganzzahl-IDs nicht so flexibel sind, so dass sie nicht einfach für Ausnahmefälle verwendet werden können. Die Entwickler des Internetprotokolls haben dies verstanden und Vorkehrungen getroffen, indem sie bestimmte Nummernblöcke auf die eine oder andere Weise als "speziell" zugewiesen haben (Broadcast-IPs, private IPs, Netzwerk-IPs). Aber das war nur möglich, weil es ein Protokoll um die Verwendung dieser Nummern gibt. Viele Datenbanken arbeiten nicht innerhalb eines so genau definierten Protokolls.

FWIW, es ist ein bisschen wie zu entscheiden, ob ein "stark typisiertes" Programmierparadigma besser ist als ein "schwach/dynamisch typisiertes" Programmierparadigma. Es hängt davon ab, was Sie tun müssen.

Answer 6

Aus der Sicht der Software ist die GUID besser als ihre weltweit einzigartige.

Zitate aus: Primary Keys: IDs versus GUIDs

eine GUID Verwendung als Zeilenidentitätswert mehr natural-- und sicherlich mehr wirklich unique-- als ein 32-Bit-Integer anfühlt. Datenbank Guru Joe Celko seems to agree. GUID-Primärschlüssel sind für viele Entwicklungsszenarios , wie Replikation, oder wenn Sie Primärschlüssel außerhalb der Datenbank generieren müssen.Aber es ist immer noch eine Frage der Abwägungen zwischen traditionellem 4-Byte-Integer-IDs ausgleichend und 16-Byte-GUIDs:

GUID Pros

• Einzigartig für jede Tabelle, jede Datenbank, jeder Server
• Ermöglicht einfaches Zusammenführen von Datensätzen aus verschiedenen Datenbanken
• Ermöglicht die einfache Verteilung von Datenbanken auf mehrere Server
• Sie können IDs generieren überall, statt Szenarien zur Datenbank
• meisten Replikation benötigen Spalt GUID sowieso

GUID Cons

• Es zu Roundtrip mit ist ein sattes 4-mal größer als der traditionelle 4-Byte-Index Wert; Dies kann schwerwiegende Performance und Speicher Auswirkungen haben, wenn du nicht aufpasst
• Cumbersome zu debuggen, wo Benutzer-ID = ‚{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}‘
• Die erzeugten GUIDs für die beste Leistung teilweise sequentiell sein sollte (zB , NEWSEQUENTIALID() auf SQL 2005) und die Verwendung von Clustered-Indizes