Warum ist der Primärschlüssel in einem relationalen Datenbankmanagementsystem oft eine ganze Zahl?

Question

In den meisten Szenarien ist es üblich, dass wir bei der Entwicklung eines Datenbankdesigns den Primärschlüssel als Integer-Typ für einen eindeutigen Bezeichner in der Tabelle festlegen. Warum nicht String oder Float für Primärschlüssel verwenden? Hat dies Auswirkungen auf die Zugänglichkeit der Werte, oder in einfachen Worten Abrufgeschwindigkeit ? Gibt es dafür besondere Gründe?

Answer 1

Eine ganze Zahl benötigt weniger Speicherplatz als eine Zeichenkette, so dass Sie eine kleinere Indexdatei durchsuchen können. Dies ist wichtig für große Tabellen, bei denen Sie so viel wie möglich vom Index im RAM zwischengespeichert haben möchten.

Außerdem können sie automatisch erhöht werden, so dass Sie keine eigenen Routinen zur Schlüsselerzeugung schreiben müssen.

Oft ist es sinnvoll, einen technischen Schlüssel (auch als Ersatzschlüssel ), ein Schlüssel, der nur zur Identifizierung der Zeile dient und für nichts anderes verwendet wird. Die meisten Daten können sich früher oder später aus Gründen ändern, die Sie nicht kontrollieren können, und Sie wollen sie nicht überall aktualisieren. Selbst so scheinbar statische Daten wie eine vom Staat zugewiesene persönliche Identifikationsnummer können sich ändern (wenn Sie eine neue Identität erhalten), oder es gibt Gesetze, die ihre Verwendung verbieten. Ein von Ihnen erzeugter Schlüssel hingegen unterliegt Ihrer eigenen Kontrolle. Für solche Ersatzschlüssel ist es nützlich, einen kleiner Schlüssel das ist leicht erstellt .

Was "Puffergrößen als Primärschlüssel" betrifft: Tun Sie das nicht. Ein Primärschlüssel sollte eine Zeile eindeutig identifizieren. Fließkommazahlen haben keine Gleichheitsbeziehung, was bedeutet, dass Sie zwei Fließkommawerte nicht sicher auf Gleichheit vergleichen können. Dies ist ein inhärentes Manko von Fließkommawerten. Wenn Sie Dezimalzahlen benötigen, verwenden Sie stattdessen einen Festkomma-Zahlentyp.

Answer 2

Der Primärschlüssel soll ein Index sein, der einen eindeutigen Weg zum Zugriff auf eine bestimmte Zeile in einer Tabelle bieten kann. Primärschlüssel können die meisten Datentypen sein (in praktischen Anwendungen funktionieren Float/Double nicht so gut), und Primärschlüssel können auch zusammengesetzte Schlüssel sein (die aus mehreren Spalten bestehen).

Wenn Sie die Daten in der Tabelle sorgfältig prüfen, können Sie möglicherweise ein Datenelement finden, das für jede Zeile in der Tabelle eindeutig ist, wodurch die Anforderung entfällt, dass Sie einen Schlüssel wie die in einigen Schemata zu findende Autoinkrement-Ganzzahl erstellen.

In einer Produktionsumgebung könnte es sich um ein alphanumerisches Feld wie eine Teilenummer oder eine Baugruppenbezeichnung handeln. Im Einzelhandel oder in der Lagerhaltung könnte es sich um eine Bestandsnummer oder eine Kombination aus Bestandsnummer/Lieferant/Hersteller handeln.

Im Allgemeinen, wenn einige Daten in Ihrer Tabelle soll ein eindeutiger Bezeichner ist es wahrscheinlich gut als Primärschlüssel für Ihre Tabelle dienen.

Durch die Verwendung von Daten, die bereits in der Tabelle vorhanden sind, entfällt die Notwendigkeit, einen Wert zu "erfinden" (z. B. die Autoinkrement-Spalte) und ihn als Primärschlüssel zu verwenden. Dies spart Platz, da es eine Spalte weniger in der Tabelle und einen Index weniger in der Tabelle gibt.

Ja, meiner Erfahrung nach sind ganzzahlige Schlüssel fast immer schneller, da es für die Datenbankmaschine effizienter ist, ganze Zahlen zu vergleichen als Zeichenketten. Abhängig von der "Einzigartigkeit" der Daten (technisch als Kardinalität bezeichnet http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ), ist die Auswirkung von Zeichen- gegenüber Ganzzahlschlüsseln nominal.

Zeichenschlüssel können die Leistung beeinträchtigen, je nach Anzahl der Zeichen, die die Datenbank vergleichen muss, um festzustellen, ob die Schlüssel gleich oder ungleich sind. Im pathologischen Fall stellen Sie sich ein Feld mit hundert Zeichen vor, die sich nur auf der rechten Seite unterscheiden. Eine Zeile hat 100 A's. Wir müssen dies mit einem Schlüssel mit 99 A's und einem B als letztem Zeichen vergleichen. Vom Konzept her vergleichen Datenbanken Zeichenfelder genau wie strcmp() ( strncmp() wenn Sie möchten) von links nach rechts.

Viel Glück!

Answer 3

Der einzige Grund ist die Leistung.

Ein logischer Datenbankentwurf sollte angeben, welche "echten" Spalten eindeutig sind, aber wenn der logische Entwurf in einen physischen Entwurf umgewandelt wird, ist es üblich, keinen dieser "natürlichen" Schlüssel als Primärschlüssel zu verwenden; stattdessen wird zu diesem Zweck eine bedeutungslose Integer-Spalte hinzugefügt - ein so genannter "Surrogatschlüssel".

Normalerweise fügt der Designer weitere eindeutige Beschränkungen für die "echten" Eindeutigkeitsregeln hinzu, wie sie im logischen Entwurf angegeben sind.

Dies liegt daran, dass die meisten DBMS Probleme haben, einen Primärschlüssel zu aktualisieren (z. B. aufgrund von Leistungsproblemen bei der Kaskadierung der Aktualisierung auf untergeordnete Tabellen). Einige DBMS können möglicherweise überhaupt keine nicht-ganzzahligen Primärschlüssel unterstützen.

Einige Randbemerkungen:

• Es gibt keinen theoretischen Grund, warum Primärschlüssel unveränderlich sein sollten.

• Dies hat nichts zu tun mit Normalisierung zu tun, die in der logischen Modell geschieht (das niemals Surrogatschlüssel haben sollte).

• Außerdem ist zu beachten, dass die Idee einer "Primärschlüssel" kein relationales Konzept ist - es ist einfach eine Art, den die "bevorzugte" Eindeutigkeit zu bezeichnen Einzigartigkeit zu bezeichnen, vielleicht für relationale Integrität - aber es gibt nichts im RM steht nichts, was besagt, dass man denselben Schlüssel für jede untergeordnete Tabelle verwenden müssen.

• Ich habe natürliche Schlüssel als "Primärschlüssel" erstellt Schlüssel" in Oracle-Datenbanken erstellt, wenn auch selten. Ich habe sie sogar schon für Fremdschlüssel-Beschränkungen verwendet. Zugegeben, sie waren entweder unveränderlich, oder ich schrieb den Aktualisierungskaskadencode von Hand geschrieben; und ich hatte Probleme mit einer Front-End Anwendung, bei der die PK eine Datumsspalte enthielt.

Fazit: Es gibt keine theoretische Voraussetzung für Ersatzschlüssel, aber sie sind viel praktischer als die Alternative.

Answer 4

Ich vermute, dass es daran liegt, dass wir Integer-Werte automatisch inkrementieren können, so dass es einfach ist, für jede Einfügung einen neuen eindeutigen Schlüssel zu erzeugen.

Answer 5

Viele gängige ORM ( Objektrelationales Mapping ) entweder zur Verwendung von Integer als Primärschlüssel zwingen oder zumindest empfehlen.

Ein Integer-Primärschlüssel spart auch Platz im Vergleich zu einem String, und ein Integer-Primärschlüssel ist in einigen Fällen auch schneller. Sequenzen oder automatisch inkrementierende Felder machen die Erzeugung von Integer-Primärschlüsseln einfach, zumindest wenn Sie nicht mit verteilten Datenbanken arbeiten.