Ich habe eine Webanwendung entwickelt und verschiedene Clients können gleichzeitig Datensätze in dieser Datenbank speichern.
Ich habe die Auto-Primärschlüsselgenerierungsfunktionalität dieser Datenbank eingestellt, die automatisch einen Primärschlüssel generiert (automatische Erhöhung), wenn ein neuer Datensatz zur Datenbank hinzugefügt wird.
Also meine Frage ist Kann ich mich auf diese Auto-Key-Generation-Funktion verlassen?
Wäre es kein Problem, wenn verschiedene Benutzer gleichzeitig Datensätze speichern?
Ja, der Autoinkrement-Primärschlüssel ist insofern zuverlässig, als ein Duplikatschlüssel niemals erzeugt wird. Sie müssen jedoch vorsichtig sein, wie Sie es verwenden.
Ich möchte noch eine weitere Sache hinzufügen, die bei der Verwendung der Funktion auto_inc von MySQL zu beachten ist:
Stellen Sie sich vor, Sie haben eine Tabelle employees , die auto_inc und (aus welchen Gründen auch immer) eine zweite Tabelle namens former_employees verwendet. Lassen Sie uns weiterhin so tun, als hätte jeder Mitarbeiter eine eindeutige ID (also die auto_inc), die ihm angehängt ist - und dass er sie nicht einmal wegen Kündigung oder Kündigung verlieren wird.
Aus Gründen der Leistung (stellen Sie sich vor, dass das Unternehmen mehrere Milliarden Mitarbeiter beschäftigt), verschiebt Ihr Unternehmen die Datensätze früherer Mitarbeiter in die gleichnamige Tabelle.
Hier ist nun ein Schnappschuss der beiden Tabellen (beachten Sie jetzt die kleinen IDs):
%Vor% Beachten Sie, dass former_employees letzte ID gleich 33 ist und dass employees auto_inc counter gleich jetzt 34 ist.
Wenn Sie den Server zu diesem Zeitpunkt herunterfahren und ihn neu starten würden, würde employees auto_inc zurück zu 33 springen !!! Das liegt daran, dass MySQL den Zähler auto_inc nicht zwischen Neustarts speichert!
Behalten Sie das im Hinterkopf. Grüße.
PS: Um dieses "Feature" zu umgehen, müssten Sie gespeicherte Prozeduren auslösen, die auf former_employees last ID schauen, und diese setzen, falls größer.
Hinweis (S.Leske): Dies gilt für InnoDB-Tabellen, nicht jedoch für MyISAM-Tabellen. Ich weiß nichts über andere Tischmotoren.
Fragen Sie, ob es jemals möglich ist, einen doppelten Schlüssel für eine IDENTITY-Spalte zu erhalten, die keine eindeutige Einschränkung hat? Ja, es ist möglich (also die Notwendigkeit von DBCC CHECKIDENT RESEED), obwohl die Wahrscheinlichkeit gering ist. Ich habe es in den letzten paar Jahrzehnten mit einer Handvoll Gelegenheiten mit SQL Server gehabt. Die einzige Möglichkeit, zuverlässig zu garantieren, dass jedes Feld eindeutig ist, ist die Verwendung einer eindeutigen Integritätsbedingung (oder Primärschlüssel-Integritätsbedingung).
Ja, diese Funktionalität funktioniert zuverlässig. Unzählige Systeme (einschließlich unserer) verwenden sie jeden Tag in der Produktion. Das DBMS enthält die entsprechenden Vorsichtsmaßnahmen, um den gleichen Wert nie zweimal zu generieren.
Es gibt einen Vorbehalt: Sie können doppelte Werte in eine Spalte einfügen, wenn Sie sie explizit einfügen (wenn das DBMS den Wert einer autoinc-Spalte explizit festlegen kann, was die meisten tun). Das mag trivial erscheinen, aber Sie können "Zeitbomben" einrichten, wenn Sie (versehentlich) einen expliziten Wert in eine autoinc-Spalte einfügen, die größer ist als die aktuelle Autoinc-ID.
Das wird gut funktionieren, bis der autoinc-Zähler den Wert erreicht, den Sie eingefügt haben, und dann "boom" (d. h. Constraint-Verletzung).
Dies kann z.B. wenn Sie Datensätze aus einer anderen Datenbank kopieren oder eine Sicherung wiederherstellen. Wir hatten das Problem auf unseren Systemen und routinemäßig Autoinc-Counter "resynchronisieren": Nach einem "gefährlichen" Update wie dem Kopieren einer ganzen DB, rufen wir den höchsten Wert für jede Autoinc-Spalte ab und setzen den Autoinc-Counter auf den Wert +1.