Eindeutige Kennungen für Benutzer

Ich würde sagen, dass vorerst ein automatisches Inkrement für die Benutzer-ID beibehalten wird.

Wenn Sie diesen plötzlichen Ansturm von Millionen von Benutzern haben, können Sie darüber nachdenken, sie zu ändern.

Mit anderen Worten, lösen Sie das Problem, wenn Sie es haben. "vorzeitige Optimierung ist die Wurzel allen Übels.".

Um die Frage zu beantworten - einige Autoinkremente ermöglichen es Ihnen, das automatische Inkrement zu seeden, so dass Sie verschiedene Autoinkremente auf den verschiedenen Knoten erhalten können. Dies wird das Problem vermeiden und trotzdem die Verwendung eines automatischen Inkrements ermöglichen.

Die Standardlösung besteht darin, eine GUID zu verwenden. Sie werden jedoch nicht so gut in Bezug auf die Indizierung funktionieren.

GUIDs sind gut, aber kollidieren (wenn auch selten).

Dies könnte eine nicht standardisierte Lösung sein, aber ich werde es da rauswerfen:

Sie können automatisch inkrementierende Zahlen verwenden, aber den Zahlenraum entsprechend der zukünftigen Verteilung aufteilen.

Nehmen wir an, Sie haben 3 Server. Notieren Sie die IDs wie folgt:

Server 1: 0 - 9.999.999
Server 2: 10.000.000 - 19.999.999
Server 3: 20.000.000 - 29.999.999

Sogar innerhalb der Einschränkungen eines 32-Bit-Int sollte dies genügend Erweiterungsraum lassen (könnte sogar Lücken von 100.000.000 nutzen, wenn Sie sich Sorgen machen), und es garantiert im Wesentlichen die Eindeutigkeit im gesamten System.

Wenn Sie Millionen von IDs benötigen und viele Knoten haben, machen Sie den Primärschlüssel zu einer Kombination aus:

ist viel besser als eine GUID (kleiner, benötigt weniger Speicher und wird schneller)

Verwenden Sie niemals natürliche Primärschlüssel, es sei denn, Sie möchten eine schlechte Leistung und das Potenzial für fehlerhafte Daten haben. Es gibt sehr wenige natürliche Schlüssel, die sich im Laufe der Zeit ändern können, insbesondere Namen. Wenn sich ein natürlicher Schlüssel ändert, müssen sich auch alle zugehörigen untergeordneten Datensätze ändern. Das ist eindeutig schlecht.

Sie könnten GUIDS verwenden. Aber 5 Millionen sind nichts in Bezug auf Daten und würden wahrscheinlich keine Änderung erfordern. Wir haben über 10.000.000 verschiedene Leute in unserem System und wir haben nur eine mittelgroße Datenbank ohne Zuteilung oder Notwendigkeit für GUIDs.

Eine GUID ist ein einfacher Ausweg, aber ...

Wie verteilt muss es sein? Wenn es sich um eine begrenzte Anzahl von Datenbanken handelt, können Sie jeder Datenbank eine Reihe von Nummern zuweisen. So erzeugt zum Beispiel die erste Datenbank auto Zahlen im Bereich von 0 bis 999.999 und die nächste verwendet 1.000.000 bis 1.999.999. Auf diese Weise können sie jeweils eine Benutzer-ID generieren, ohne sich gegenseitig anzustoßen. Wenn die Datenbank eine eindeutige Nummer enthält, die sie identifiziert, können die Bereiche automatisch aus dieser Nummer generiert werden.

Ich glaube nicht, dass Sie dafür eine Autoinkrement-Spalte verwenden können, aber eine gespeicherte Prozedur könnte auf diese Weise Zahlen erzeugen.

Wenn Sie MSSQL verwenden, können Sie die PK Ihrer Tabelle als UNIQUEIDENTIFIER erstellen und den Standardwert oder die Bindung an NEWID () festlegen.

Ich schlage vor, dass du GUIDs nie in Betracht ziehst, weil ich momentan Probleme mit ihnen habe. Angenommen, du hast Millionen von Benutzern, dann brauchst du vielleicht einen größeren Grad an Parallelität und Guids ruinieren dein Leben, während Du es einfügen und löschen kannst haben einen Index auf ihnen und in der Voreinstellung wird es ein gruppierter Index sein, der bedeutet, wenn Sie einen geclusterten Index jedes einfügen und löschen den Eintrag physikalisch bewegen und außerdem sind Guids nicht sequentiell, so würde es eine Chance von Null geben, dass jeder neue Einsatz kommt ganz unten oder oben auf der Seite. Daher wird der gesamte Einfüge- und Löschvorgang sehr kostspielig und wenn Sie den Index entfernen, wird Ihre Auswahl teuer.

Insbesondere, wenn Sie mehrere Tabellen haben und Beziehungen zwischen ihnen bestehen, betrachten Sie Guids nicht als Primärschlüssel.

Es gibt folgende Zwei-Lösung, die ich empfehlen würde.

1. Wenn Sie Composite-Schlüssel erstellen können, die perfekt sind, als wäre eine Banksoftware dann branchId, wird transactionId der Primärschlüssel, wobei branchId die Identität des Knotens ist, der den Datensatz einfügt, und transactionId ist eine automatische Nummer verzweigen, so erhalten Sie die Einzigartigkeit den ganzen Weg.

2. Wenn oben nicht das ist, was Sie gerne tun oder in Betracht ziehen, dann können Sie die Guid als eindeutiges Feld verwenden, aber eine Autoinkrementnummer als Primärschlüssel hinzufügen, was Ihnen hilft, die Gesamtkosten zu reduzieren, wie beim Client (Knoten) ) sendet Daten mit (Web Service) RPC dann müssen Sie Datensatz in Server-Datenbank einfügen, dann wird eine automatische Nummer generiert und diese Autonummer kann für zukünftige Auswahl, löschen oder aktualisieren, aber Client nicht über diese Autonummer

   wissen müssen

Ich verstehe, dass die zweite Lösung ein wenig verwirrend und komplex ist, aber es ist immer noch besser als die Verwendung von Guids als PK. aber wenn Lösung 1 anwendbar ist, gehen Sie dafür.

Wenn ich sage, dass Kosten nicht nur die Verarbeitungszeit, sondern auch die Sperrzeit sind, ist das völlig Geldverschwendung und Ihr Quad-Core-Server kann die Hälfte davon ausführen, und mehr Sperren bedeuten mehr Chancen auf Deadlocks mein Freund benutzt niemals Guids.

Grüße Mubashar