Welcher Datentyp wird für ID-Spalten empfohlen?

Beliebiger ganzzahliger Typ mit ausreichender Größe zum Speichern antizipierter Datenbereiche. Im Allgemeinen werden 32-Bit-Ints für Tabellen mit vielen Zeilen oder Änderungen als zu klein (richtig oder falsch) angesehen. Ein 64-Bit-Int ist reichlich. Viele Datenbanken verwenden diesen Integer-Typ nicht oder verwenden ihn nicht, verwenden jedoch einen NUMBER-Typ mit angegebener Skalierung und Genauigkeit. 10-15 Ziffern ist eine ziemlich häufige Größe.

Der Grund für die Auswahl von Integertypen ist zweifach:

1. Größe; und
2. Geschwindigkeit.

Die Größe einer Ganzzahl ist:

• 32 Bit: 4 Bytes;
• 64 Bit: 8 Bytes;
• Binär codierte Dezimalzahl: zwei Ziffern pro Byte plus soviel wie ein Byte für Zeichen, Maßstab und / oder Genauigkeit.

Vergleichen Sie das mit einer GUID , die 128 Bit oder eine normale Zeichenkette ist, die mindestens ein Byte pro Zeichen ist (Mehr in bestimmten Zeichenkodierungen) plus einem Overhead, der so klein wie ein Byte sein kann (NULL beendend) oder in einigen Fällen viel mehr sein kann.

Die Sortierung ganzer Zahlen ist trivial und unter der Annahme, dass sie einzigartig sind und der Bereich ausreichend klein ist, kann tatsächlich in O (n) Zeit verglichen mit bestenfalls O (n log n) durchgeführt werden.

Ebenso wichtig ist, dass die meisten Datenbanken eindeutige IDs mit Hilfe von Auto-Increment-Spalten und / oder -Sequenzen erzeugen können. Das Garantieren der Eindeutigkeit in einer Anwendung ist ansonsten tatsächlich ziemlich schwierig und führt oft zu aufgeblähten Schlüsseln.

Plus automatisch generierte Integer-Schlüssel sind in der Regel entweder lose oder absolut geordnet (abhängig von Datenbank und Konfiguration), was eine nützliche Eigenschaft ist. Zufällig generierte GUIDs sind grundsätzlich ungeordnet, was weit weniger sinnvoll ist.

Populäre Datenbanken erlauben seit Jahren größere Autoinkrement-Felder und sind daher viel weniger problematisch.

Was zu verwenden ist, ist es immer eine Wahl. Eines ist nicht eindeutig besser als das andere, sie haben unterschiedliche Eigenschaften und jedes ist in verschiedenen Szenarien gut. Ich habe beide im Laufe der Zeit verwendet, und das nächste Schema, mit dem ich arbeite, werde ich beide berücksichtigen.

Vorteile für GUID:

• Sollte auf allen Computern eindeutig sein.
• Zufälliges, nicht wahrnehmbares Goo bedeutet, dass Personen dieses nur für den beabsichtigten Zweck eines undurchsichtigen Identifikators verwenden.

Vorteile für Autoinkrement:

• Mensch verständlich.
• Sequenzielle Zuweisung bedeutet, dass Sie einen Clustered-Index verwenden und die Leistung beeinflussen können.
• Geeignet für die Datenpartitionierung.

Ein großer Nachteil der Verwendung von GUID-Schlüsseln besteht darin, dass es schwierig ist, "Ad-hoc" -Abfragen von Hand auszuführen. Manchmal ist es sehr nützlich, dass Sie dies tun können:

SELECT * FROM Benutzer mit UserID = 452245

Mit GUID-Tasten kann das sehr nervig werden.

Ich würde 64 Bit Ganzzahlen empfehlen

Sagen Sie mir, welche Kriterien Sie für wichtig halten.

Was erforderlich ist muss innerhalb der Tabelle eindeutig sein.

Eine GUID ist eine globale probabilistisch eindeutige Kennung. Es ist auch groß. Wenn Sie möchten, dass Ihre Indizes innerhalb jeder einzelnen Datenbankinstallation im Universum eindeutig innerhalb von epsilon sind, ist dies eine gute Wahl. Ansonsten wird unnötig viel Platz benötigt.

Eine Autoinkrementierungsnummer ist gut; Es ist klein und sicher einzigartig in der Tabelle. Auf der anderen Seite gibt es keinen Schutz vor Doppelarbeit; zwei Einträge, die bis auf die magische Zahl identisch sind, sind einfach zu erstellen.

Wenn Sie einen Wert verwenden, der an die Entität gebunden ist, die Sie beschreiben, vermeiden Sie das, aber Sie haben das Problem, mit der Eindeutigkeit umzugehen.

Wenn Sie eine lange verwenden, können Sie mehr als 1000 pro Sekunde erstellen und die Primärschlüssel für 29 Millionen Jahre nicht ausgehen.

Andere haben bereits einige der Vorteile der Verwendung eines Integer-Typs anstelle einer UUID / GUID erwähnt. Einer der großen Vorteile ist die Geschwindigkeit und Kompaktheit der Indizes.

Eine Anwendung, an der ich kürzlich beteiligt war, wo ich den Datenbankentwurf machte, benötigte UUIDs, wollte aber die Vorteile der Verwendung von Longs für Primärschlüssel nicht aufgeben, daher hatte ich eine "allIds" -Tabelle, die alle Primärdaten abbildete Geben Sie das System in eine UUID ein. Alle meine Primärschlüssel wurden aus einer einzigen Sequenz generiert, so dass sie alle in allen Tabellen eindeutig waren.

Wenn die Datenbank verteilt ist und Sie Datensätze von anderen Datenbanken abrufen können, muss der Primärschlüssel innerhalb einer Tabelle für alle Datenbanken eindeutig sein . GUID löst dieses Problem, allerdings auf Kosten des Platzes. Eine Kombination aus Autoincrement und Namespace wäre ein guter Kompromiss.

Es wäre schön, wenn Datenbanken Autoinkremente mit "Präfixen" unterstützen könnten. So bekomme ich in einer Datenbank IDs wie X1, X2, X3 usw., während es in der anderen Datenbank Y1, Y2, Y3 usw. sein kann.

Ich habe eine ähnliche Frage gestellt, die einige Antworten enthält, die helfen könnten. Replikation scheint der größte Vorteil der Verwendung von GUIDs zu sein.

Gründe nicht zu verwenden Automatisch inkrementierende Nummer für einen Primärschlüssel

Folge Cletus 'Rat, mit der zusätzlichen Einschränkung davon hängt weitgehend davon ab, was Sie storting. Verwenden Sie niemals eine GUID. GUIDs haben ein ganzes Bündel von Schattenseiten und nur ein oder zwei Vorteile.