[MYSQL] Primary Key doppelt pflegen

[bermany]

Hallo Forengemeinde,

mich würde interessieren, ob es einen eleganten Weg gibt, bei einem INSERT den Primary-Wert in einer zweiten Spalte noch einmal abzulegen, etwa so:

INSERT INTO table ( id , id2 , irgendwas ) VALUES ( NULL , id , 'irgendwas' ) ;

Das Beispiel füllt zwar id aufgrund Primary+auto_increment korrekt aus, id2 jedoch nicht.

Bislang habe ich immer die Insert_id ermittelt und mittels zweitem Aufruf id2 gefüttert. Geht das eleganter?

 

[rico2009]

Nein, nicht das ich wüsste. Du musst das in 2 Abfragen machen, da du die neue ID ja erst bekommst, wenn die Abfrage abschlossen wurde. (Aber es gibt in MySQL die Funktion last_insert_id() (https://dev.mysql.com/doc/refman/5.0/en/information-functions.html#function_last-insert-id), vllt. hilft dir das weiter.)

 

[jspit]

Geht schon mit einer Abfrage, ist aber nicht besonders schnell:

INSERT INTO test (id2) VALUES ((SELECT MAX(id) FROM test t2) + 1)

Ist aber nur für das erste INSERT einer Sitzung notwendig. Dann steht ja die last_insert_id() zu Verfügung.
Für alle weitere kann dann

INSERT INTO TEST (id2) VALUES (last_insert_id()+1)

genommen werden. Ob dir dies was bringt?

LG jspit

 

[kkapsner]

Die Frage ist eher, warum du das machen willst/musst?

PS: Die beiden Queries kannst du gleichzeitig an MySQL übergeben

INSERT INTO `table` (`irgendwas`) VALUES ('irgendwas');
UPDATE `test` SET `id2` = `id` WHERE `id` = LAST_INSERT_ID()

- ob das oder jspits Query schneller ist, müsstest du ausprobieren.

 

[bermany]

Danke für Eure Antworten.

Die Frage ist eher, warum du das machen willst/musst?

Die Frage war vorhersehbar, aber ich will die Neugier befriedigen:
Es handelt sich um ein Sortierkriterium, dass in der Voreinstellung die Erfassungsreihenfolge festhält und durch Usereingriffe geändert werden kann. Dabei wird id2 lediglich mit dem vorhergehenden bzw. nachfolgenden Datensatz getauscht.

@jspit last_insert_id liefert bei einer leeren Tabelle 0, sodass mit last_insert_id()+1 doch eigentlich schon beim ersten Datensatz alles korrekt laufen müsste.
Das könnte ein guter Ansatz sein, da keine Importe etc. ausgeführt werden. Geschwindigkeit ist also kein Problem.
Danke nochmal.

 

[jspit]

Die Bemerkung "nicht besonders schnell" betrifft nur die erste Abfrage mit dem Subselect.

 

[SteelWheel]

Theoretisch könntest Du folgende Idee adaptieren: Reserviere das Feld, benutze es aber erst "bei Bedarf"! Beim ersten Anfassen durch einen User (die erwähnte Modifikation) berücksichtigst Du die reguläre id (auto_inc); alle ohne "id2" stellst Du hinten an – Kriterium gem. "id" (asc/desc). Sortiert der User neu (up/down), setzt Du Deinen Wert in "id2". So umgehst Du den zweiten Query bzw. Subselects oder gar unnötige Aktionen. Das heißt, dass beim Auslesen alle Datensätze abgeholt werden. Alle mit "id2" haben Priorität in der Anordnung. Alle "ohne" stellst Du hinten an in Deiner GUI.

Ist vielleicht eine ganz andere Herangehensweise, um ein wenig Ressourcen zu schonen.

 

[kkapsner]

Ich bin mir nicht sicher, ob diese Herangehensweise wirklich Ressourcen schont. Die Sortierung benötigt mehr, da man dann über zwei Spalten sortiert.

Auch würde ich das als Nutzer als unintuitiv empfinden...

 

[bermany]

Naja, der Nutzer sieht die Werte nicht, für ihn ist die Reihenfolge eher ein Bauchgefühl. Am besten ist das wohl mit Rechnungspositionen zu vergleichen, wo die Reihenfolge im Grunde völlig egal ist, der Nutzer aber trotzdem eine gefühlte Stunde lang rumsortiert.
Aber die Zweistufige Sortierung wird m.E. auch mehr Ressourcen verschlingen, als bei der Erfassung erspart wurden.

Was ich halt nicht wusste ist, dass man last_insert_id in einer Query direkt verwenden kann. Ich kannte die Funktion nur als PHP-Funktion.

 

[SteelWheel]

Guten Morgen,

da ich die Anzahl der Einträge, die ein User so haben kann, in meiner Vorstellung nicht auf "unendlich" gesteckt hatte, ist mir "sortierfertig aus der DB" wohl irgendwie durchgerutscht. Das tut mir leid - auch die Verwirrung. Ich hatte nicht die Absicht via DB über zwei Spalten zu sortieren, sondern die finale Aufbereitung zur Ausgabe über bspw. PHP vorzunehmen. Die DB gibt mir ein schönes Array zurück, womit ich dann mit zwei Schritten (nach DB) am Ziel wäre:
- entnehme Zeilen ohne "id2"-Befüllung (parke in eigenem Array)
- Sortiere gem. "id2"
- (ok ... drei ... und hänge "unordered" die Unbefüllten wieder an)

Es war nur ein Vorschlag, um "vorwärts zu kommen" – also nicht gleich wieder Messer wetzen.

Abflug ... Agentur ruft!

 

[kkapsner]

Was ich halt nicht wusste ist, dass man last_insert_id in einer Query direkt verwenden kann. Ich kannte die Funktion nur als PHP-Funktion.

Man lernt hald nie aus...

@Steel: Hm... ich denke, dass zwei Queries gegen die DB noch langsamer sind. Das muss ja dann bei jedem Betrachten ausgeführt werden. Das Modifizieren oder die Sortierung in der DB müsen ja nur dann gemacht werden, wenn etwas in der Tabelle geändert wird (natürlich nur bei einem passenden Index).

Es war nur ein Vorschlag, um "vorwärts zu kommen" – also nicht gleich wieder Messer wetzen.

Keiner wetzt hier irgendwas.

 

[SteelWheel]

Ich hatte nicht von zwei Queries gesprochen oder diese als Lösung vorgeschlagen.

 

[kkapsner]

Dann hatte ich dich falsch verstanden...

 

[SteelWheel]

Alles halb so schlimm - ist schließlich Wochenende.