Sollte ich meine AUTO_INCREMENT ID-Spalte auf 2^32 + 1 statt 0 initialisieren?

Question

Ich entwerfe ein neues System zum Speichern von Kurzmitteilungen [sic].

Ich werde jede Nachricht durch einen eindeutigen Bezeichner in der Datenbank identifizieren und eine AUTO_INCREMENT -Spalte verwenden, um diese Bezeichner zu generieren.

Herkömmliche Weisheit sagt, dass es okay ist, mit 0 zu beginnen und meine Nachrichten von dort zu nummerieren, aber ich bin besorgt über die Langlebigkeit meines Dienstes. Wenn ich eine externe API mache und es zu 2^31 Nachrichten mache, haben einige Leute, die die API benutzen, meine Kennung fälschlicherweise in einer vorzeichenbehafteten 32-Bit-Ganzzahl gespeichert. An diesem Punkt würden sie überlaufen oder abstürzen oder etwas Schreckliches würde passieren. Ich möchte diese Art von Foo-Pocalypse, wenn möglich, vermeiden.

Sollte ich "UPDATE Nachricht SET ID = 2^32 + 1;" bevor ich meinen Dienst starte und alle dazu zwinge, meine Kennungen von Anfang an als signierte 64-Bit-Nummern zu speichern?

Answer 1

Wenn Sie Ihr Ziel erreichen wollten und die Probleme vermeiden wollten, die cletus erwähnte, ist die Lösung, Ihren Startwert auf 2^32 + 1 zu setzen. Es gibt immer noch genug IDs, und es passt nicht in einen 32-Bit-Wert, signiert oder nicht.

Natürlich ist es die einzig richtige Lösung, den Wertebereich zu dokumentieren und Ihren API- oder Datenkunden eine Anleitung zu geben. Jemand wird immer versuchen, lange in ein Zeichen zu stecken und sich fragen, warum es nicht funktioniert (immer)

Answer 2

Tatsächlich kann 0 mit vielen Persistenzbibliotheken problematisch sein. Das liegt daran, dass sie es als eine Art Sentinel-Wert verwenden (ein Ersatz für NULL). Zu Recht oder zu Unrecht würde ich vermeiden, 0 als Primärschlüsselwert zu verwenden. Die Konvention soll bei 1 beginnen und nach oben gehen. Bei negativen Zahlen werden Sie die Leute wahrscheinlich ohne guten Grund verwirren.

Answer 3

Was wäre, wenn Sie eine Reihe von Test-Suites oder einen Test-Service zur Verfügung gestellt, die Nachrichten in der "High, aber immer noch gültig "Bereich und überzeugen Sie Ihre Service-Nutzer, sie zu verwenden, um ihren Code zu validieren ist richtig? Ausgehend von einem willkürlichen Wert aus defensiven Gründen ist es etwas komisch für mich; Die Bereitstellung von Gesundheitstests reibt mich richtig.

Answer 4

Wenn alle lebenden auf dem Planeten eine Nachricht pro Sekunde jede Sekunde non-stop gesendet haben, würde Ihr Zähler nicht bis zum Jahr mit 64-Bit-Ganzzahlen wickeln.

Wahrscheinlich würde nur bei 1 beginnen würde ausreichen.

(Aber wenn Sie an der unteren Grenze beginnen würde, würde es in den Anfang 2092 erweitern)

Answer 5

Ich will nicht der nächste Twitter sein, nicht wahr? lol

Wenn Sie Bedenken hinsichtlich der Skalierbarkeit haben, sollten Sie stattdessen eine GUID (uniqueidentifier) ​​verwenden.

Sie sind nur 16 Bytes (doppelt so groß wie ein bigint), aber sie können unabhängig voneinander auf mehreren Datenbank- oder BL-Servern zugewiesen werden, ohne sich um Kollisionen kümmern zu müssen.

Da sie zufällig sind, verwenden Sie NEWSEQUENTIALID() (in SQL Server) oder eine COMB-Technik (in Ihrer Geschäftslogik oder Pre-MSSQL 2005-Datenbank), um sicherzustellen, dass jede GUID "höher" ist als die letzte (Geschwindigkeiten fügt ein in deinen Tisch).

Wenn Sie mit einer so hohen Zahl beginnen, werden einige "Genie" -Programmierer entweder 2^32 subtrahieren, um sie in ein int zu drücken, oder ignorieren einfach die erste Ziffer (die "immer gleich" ist) erste Milliarde Nachrichten).

Answer 6

Warum inkrementierende IDs verwenden? Diese erfordern eine Sperrung und werden jegliche Pläne zur Verteilung Ihres Dienstes über mehrere Maschinen zunichte machen. Ich würde UUIDs verwenden. API-Benutzer werden diese wahrscheinlich als undurchsichtige Zeichenketten speichern, was bedeutet, dass Sie das Schema wahrscheinlich später ändern können, wenn Sie möchten.

Wenn Sie wollen sicherstellen, dass Nachrichten einen Auftrag haben, die Bestellung wie eine verkettete Liste implementieren:

--- 
id: 61746144-3A3A-5555-4944-3D5343414C41 
msg: "Hello, world" 
next: 006F6F66-0000-0000-655F-444E53000000 
prev: null 
posted_by: jrockway 
--- 
id: 006F6F66-0000-0000-655F-444E5300000 
msg: "This is my second message EVER!" 
next: 00726162-0000-0000-655F-444E53000000 
prev: 61746144-3A3A-5555-4944-3D5343414C41 
posted_by: jrockway 
--- 
id: 00726162-0000-0000-655F-444E53000000 
msg: "OH HAI" 
next: null 
prev: 006F6F66-0000-0000-655F-444E5300000 
posted_by: jrockway 

(Als beiseite, wenn Sie tatsächlich die Ergebnisse als YAML Rückkehr sind, können Sie & verwenden und * Referenzen statt nur die IDs als Daten zu verwenden.Dann erhält der Client die verknüpfte Listenstruktur "kostenlos".)

Answer 7

Eine Sache, die ich nicht verstehe, ist, warum Entwickler nicht begreifen, dass sie nicht müssen ihr AUTO_INCREMENT Feld freilegen. Zum Beispiel wird richardtallent mit Guids als Primärschlüssel erwähnt. Ich sage, mach es besser. Verwenden Sie einen 64-Bit-Int für Ihre Tabellen-ID/den Primärschlüssel, aber verwenden Sie auch eine GUID oder etwas Ähnliches als Ihre öffentlich zugängliche ID.

Ein Beispiel Message Tabelle:

Name   | Data Type 
------------------------------------- 
Id    | BigInt - Primary Key 
Code   | Guid 
Message  | Text 
DateCreated | DateTime 

Dann sieht Ihre Daten wie:

Id | Code         Message DateCreated 
------------------------------------------------------------------------------- 
1 | 81e3ab7e-dde8-4c43-b9eb-4915966cf2c4 | ....... | 2008-09-25T19:07:32-07:00 
2 | c69a5ca7-f984-43dd-8884-c24c7e01720d | ....... | 2007-07-22T18:00:02-07:00 
3 | dc17db92-a62a-4571-b5bf-d1619210245a | ....... | 2001-01-09T06:04:22-08:00 
4 | 700910f9-a191-4f63-9e80-bdc691b0c67f | ....... | 2004-08-06T15:44:04-07:00 
5 | 3b094cf9-f6ab-458e-965d-8bda6afeb54d | ....... | 2005-07-16T18:10:51-07:00 

Wo Code ist, was Sie für die Öffentlichkeit aussetzen würde, ob es sich um eine URL, Dienstleistung, CSV, XML sein usw.