Holen Sie sich die generierte uuid nach einfügen php
habe ich ein Feld einer Tabelle vom Typ varchar(36) und ich will ihn zu erzeugen, die dynamisch durch mysql so habe ich diese code:
$sql_code = 'insert into table1 (id, text) values (uuid(),'some text');';
mysql_query($sql_code);
wie kann ich rufen Sie die generierte uuid sofort nach dem einlegen der Scheibe ?
- Ist dein id-Feld ist ein einmalige?
- glaubst du es ist möglich die UUID-Kollisionen in unserem Universum? 😉
- Nein 🙂 aber wenn ich mich Recht erinnere,
LAST_INSERT_ID()
funktioniert nur auf unique-Spalten, daher meine Frage - noch mehr, es funktioniert nur mit autoincrement diejenigen, die, wenn ich mich Recht erinnere, sind einzigartig durch die definitio.
- ah, fair genug.
- pardon 🙁
- was für? 🙂
Du musst angemeldet sein, um einen Kommentar abzugeben.
char(36)
ist besserkönnen Sie nicht. Die einzige Lösung ist, führen Sie 2 getrennte Abfragen:
SELECT UUID()
INSERT INTO table1 (id, text) VALUES ($uuid, 'text')
wobei $uuid ist der Wert abgerufen am 1. Schritt.
CHAR(36)
wird 3*36 Byte lange UTF-8, plus die Länge byte(s). Damit Ihre besten Optionen wären (A) etwas mit binären, (B)ASCII CHAR
oder (C)VARCHAR
.UUID()
Charaktere sind alle einzelnen bytes. Bitte prüfen Sie, wie genau die utf-8 codiert unicode-codepoints, wenn Sie sich entscheiden, weiter zu diskutieren.CHAR(36)
hängt von den Daten, die könnte sein (definiert durch den Zeichensatz), nicht auf die Daten, die Sie nur geschehen, um die Speicherung in es zu dieser Zeit. Ja, für UUID (), wäre es nicht müssen zu sein, so groß, wie es ist. Aber (wenn UTF-8) sind Sie perfekt speichern darf, 36 japanische Zeichen in es zu jeder Zeit, die nehmen viel mehr Platz, und die Spalte hat bereits reserviert ist der Platz um dies möglich zu machen, ob Sie es verwenden oder nicht. Ein Grund, vorsichtig zu sein, mit UTF-8CHAR
.Können Sie alles, was Sie tun müssen, um mit SQL-Trigger. Die folgende SQL-fügt einen trigger auf
tablename.table_id
automatisch zu erstellen, die primary key-UUID beim einfügen, dann speichert die neu erstellte ID in eine SQL-variable für den Abruf später:Als bonus, es fügt die UUID in binärer form zu einem binary(16) - Feld, um Speicherplatz zu sparen und erhöhen die abfragegeschwindigkeit.
edit: der trigger sollte geprüft werden, ob eine vorhandene Spalte Wert vor dem einfügen Ihrer eigenen UUID, um zu imitieren, die Fähigkeit zum bereitstellen von Werten für die Tabelle ein Primärschlüssel in MySQL - ohne diese, werden alle Werte übergeben, wird immer überschrieben werden, indem der Auslöser. Das Beispiel wurde aktualisiert, um zu verwenden
ASCII() = 0
zu prüfen, die Existenz der primary key-Wert in der INSERT -, der wird erkennen, leeren string-Werten für ein binäres Feld.edit 2: nach einem Kommentar hier seitdem hat er mich darauf hingewiesen, dass die Verwendung
BEFORE INSERT
hat den Effekt der@last_uuid
variable, auch wenn die Zeile insert schlägt fehl. Ich aktualisiert meine Antwort zu verwendenAFTER INSERT
- während ich das Gefühl, das ist eine ganz feine Konzept unter Allgemeinen Umständen kann es Probleme mit Zeilen-Replikation im Rahmen der Cluster-oder replizierten Datenbanken. Wenn jemand weiß, würde ich gerne, wie gut!Lesen der neuen Zeile ist die insert ID zurück, führen Sie einfach
SELECT @last_uuid
.Wenn Sie Abfragen und Lesen solchen binäre Werte, die MySQL-Funktionen
HEX()
undUNHEX()
wird sehr hilfreich sein, so wird das schreiben Ihrer Abfrage Werte in hex-notation (vorangestellt0x
). Der php-code für deine ursprüngliche Antwort, da diese Art von trigger angewendet Tabelle1, wäre:Folgende Reaktion auf @ina Kommentar:
Einer UUID ist kein string, auch wenn MySQL wählt zu Ihrer Vertretung als solche. Es ist binären Daten in Ihrer rohen form, und diese Striche sind nur die MySQL-freundliche Art, dass er ihn zu Ihnen.
Die effiziente Speicherung für eine UUID ist, es zu schaffen, als
UNHEX(REPLACE(UUID(),'-',''))
- dies wird auch entfernen, formatieren und konvertieren Sie Sie zurück, um binäre Daten. Diese Funktionen machen die ursprüngliche insertion langsamer, aber alle folgenden Vergleiche auf diese Taste oder die Spalte wird sehr viel schneller auf eine 16-byte-binary-Feld als ein 36-Zeichenfolge.Für ein -, Zeichen-Daten erfordert die Analyse und Lokalisierung. Alle Zeichenfolgen, die kommen, um die Abfrage-engine sind in der Regel sortiert automatisch gegen den Zeichensatz der Datenbank, und einige APIs (wordpress in den Sinn kommt) auch laufen
CONVERT()
auf alle string-Daten vor dem Abfragen. Binäre Daten nicht über diese overhead. Für die anderen, Ihrechar(36)
ist eigentlich Zuteilung von 36 Zeichen, was bedeutet, dass (wenn deine Datenbank UTF-8) jeder Charakter kann so lange, wie 3 oder 4 bytes je nach MySQL-version Sie verwenden. So einchar(36)
kann irgendwo im Bereich von 36 Byte (wenn es besteht ausschließlich aus low-ASCII-Zeichen) 144 wenn die ausschließlich aus high-order-UTF8-Zeichen. Dies ist viel größer als die 16 bytes, die wir reserviert haben für unsere binären Bereich.Jeder Logik durchgeführt, die auf diese Daten kann getan werden, mit
UNHEX()
, aber es ist besser erreicht, indem einfach die Flucht von Daten in Abfragen als hex -, Präfix mit0x
. Dies ist nur so schnell wie das Lesen einer Zeichenkette, wird in das Binärformat konvertiert on-the-fly und direkt zugeordnet, um die Abfrage oder der Zelle in Frage. Sehr schnell.Das Lesen von Daten aus ist, etwas langsamer zu nennen
HEX()
auf alle binären Daten Auslesen einer Abfrage, um es in ein brauchbares format, wenn Ihr client-API sich nicht gut mit Binär-Daten (PHP in paricular wird in der Regel feststellen, dass binäre Zeichenfolgen=== null
und wird brechen, wenn Sie manipuliert werden, ohne ersten aufrufendenbin2hex()
,base64_encode()
oder ähnliches) - aber dieser Aufwand ist ungefähr so minimal, wie Charakter-Sortierung und-viel wichtiger-wird nur aufgerufen, die eigentlichen ZellenSELECT
ed, nicht alle Zellen, die in die internen Berechnungen, die von einem Abfrage-Ergebnis.So natürlich, all diese kleinen Geschwindigkeit erhöht sehr minimal und in anderen Bereichen führen kleine abnimmt - aber wenn Sie fügen Sie Sie alle bis
binary
kommt immer noch an der Spitze, und wenn man bedenkt, use cases und den Allgemeinen lese - > schreibt den Grundsatz " es wirklich glänzt.... und das ist der Grund, warum
binary(16)
ist besser alschar(36)
.BEFORE INSERT
auslösen, sehen Sie bitte edit2 Hinweis (:Seine ziemlich einfach eigentlich
übergeben Sie diese zu mysql und es wird wieder die id eingefügt.
Je nachdem, wie die uuid () - Funktion implementiert ist, das ist sehr schlechter Programmierstil - wenn Sie dies versuchen mit binären die Protokollierung aktiviert ist (z.B. in einem cluster), dann einfügen wird höchstwahrscheinlich fehlschlagen. Iwan ' s Vorschlag sieht es vielleicht lösen das unmittelbare problem - aber ich dachte, diese nur zurückgegeben, der generierte Wert für ein auto-Inkrement-Feld - in der Tat, dass die was das Handbuch sagt.
Auch was ist der Vorteil der Verwendung einer uuid()? Seine rechenintensiv zu generieren, erfordert eine Menge Speicher, erhöht die Kosten für die Abfrage der Daten und ist nicht kryptographisch sicher. Mit einer Sequenz-generator oder autoincrement statt.
Unabhängig davon, ob Sie eine Sequenz-generator oder die uuid, wenn Sie müssen, verwenden Sie diese als einzige unique key in der Datenbank, dann werden Sie brauchen, um den Wert zuzuweisen erste, Lesen Sie es wieder in phpland und einbetten/bind den Wert als literal in die nachfolgenden insert-Abfrage.
INSERT
trigger bedeutet, dass die Knoten zuständig für die Generierung der Zeile erstellt die Schlüssel bei der Ausführung der Transaktion, und dieser Schlüssel wird dann in die zur Verfügung gestellten Daten zu anderen Knoten, wenn die Daten, die Kaskaden an replizierten Tabellen.