MySQL - autoincrement temporär ausser Kraft setzen

[FrankieB]

Hallo,

ich möchte bei manchen Aktionen gerne die "autoincrement"-Eigenschaft in MySQL zeitweise ausser Kraft setzen.

Ich bin mir schon bewusst, daß "autoincrement" Sinn macht, ansonsten würde ich es nicht verwenden.

Grund:
Wenn ich z.B. ein Backup einspiele will/muss, tritt manchmal der Fall auf, daß ein DS gelöscht wurde und mit seiner ursprünglichen Position/id wieder hergestellt werden soll. Diese Position kann natürlich auch "zwischen" den bestehenden ids liegen, da z.B. ein DS zwischenzeitlich gelöscht wurde, aber wieder hergestellt werden soll.

Wie kann man das handeln?

Danke & Gruss
Frankie

P.S.:
Mit Update und Insert habe ich keinerlei Probleme, es geht mir nur darum, einen DS mit einer schon vergebenen id zu schreiben, was dem Sinn von "autoincrement" eigentlich wiederspricht.
Bei Update kenne ich die id und der DS ist vorhanden, bei Insert nimmt MySQL den nächsten autoincrement"-Wert, aber einen DS dazwischenzuschieben will mir einfach nicht gelingen.

[Rouven]

Hi,

also da fällt mir keine Lösung im Sinne "kein Autoincrement" ein, sondern ich schlage vor, guck dir doch den wiederherzustellenden Datensatz an und füge ihn ein, als wäre es ein neuer Datensatz. Die Routinen, auch für sämtliche Fremdschlüsselbeziehungen, müsstest du doch irgendwo für das Insert eh haben, also tu einfach so als _wäre_ das ein neuer Datensatz, dann hast du das Problem nicht.

MfG
Rouven

[FrankieB]

Hallo Rouven,

tut mir leid, dich mit TomIRL temporär verwechselt zu haben ...

Hi,

also da fällt mir keine Lösung im Sinne "kein Autoincrement" ein, sondern ich schlage vor, guck dir doch den wiederherzustellenden Datensatz an und füge ihn ein, als wäre es ein neuer Datensatz.

genau das möchte ich nicht, da ich dann beim Update einer Tabelle alle verknüpften auch updaten müsste.

Die Routinen, auch für sämtliche Fremdschlüsselbeziehungen, müsstest du doch irgendwo für das Insert eh haben, also tu einfach so als _wäre_ das ein neuer Datensatz, dann hast du das Problem nicht.

das mache ich bereits so, aber ich dachte es gäbe irgendeine elegantere Lösung.

Ich habe schon mal von ... IGNORE gelesen, aber nicht im Zusammenhang mit meinem Problem.

Gruss
Frankie

[TomIRL]

Hallo,

ich möchte bei manchen Aktionen gerne die "autoincrement"-Eigenschaft in MySQL zeitweise ausser Kraft setzen.

Ich bin mir schon bewusst, daß "autoincrement" Sinn macht, ansonsten würde ich es nicht verwenden.

Grund:
Wenn ich z.B. ein Backup einspiele will/muss, tritt manchmal der Fall auf, daß ein DS gelöscht wurde und mit seiner ursprünglichen Position/id wieder hergestellt werden soll. Diese Position kann natürlich auch "zwischen" den bestehenden ids liegen, da z.B. ein DS zwischenzeitlich gelöscht wurde, aber wieder hergestellt werden soll.

Das leuchtet mir nicht ein..
Also bei mir ist es vollkommen egal welche id ein Datensatz besitzt
Alle weiteren Informationen liegen in anderen Feldern der Tabelle..
Ausserden erkläre doch mal bitte WIE Du ein Update machst, dass Du Dein Ziel überhaupt erreichst..

Meiner Ansicht nach liegt das Problem vor dem Bildschirm

TomIRL

[FrankieB]

Hallo Rouven,

Das leuchtet mir nicht ein..
Also bei mir ist es vollkommen egal welche id ein Datensatz besitzt

Natürlich ist das egal, aber wenn Verknüpfungen über die ID erfolgen ist das nicht mehr egal.

Alle weiteren Informationen liegen in anderen Feldern der Tabelle..
Ausserden erkläre doch mal bitte WIE Du ein Update machst, dass Du Dein Ziel überhaupt erreichst..

Ich mache dieses Update via SQL, also nicht über Sicherung der Dateien.

Meiner Ansicht nach liegt das Problem vor dem Bildschirm

Das kann durchaus sein.

Frankie

[TomIRL]

Hallo Frankie

Alle weiteren Informationen liegen in anderen Feldern der Tabelle..
Ausserden erkläre doch mal bitte WIE Du ein Update machst, dass Du Dein Ziel überhaupt erreichst..

Ich mache dieses Update via SQL, also nicht über Sicherung der Dateien.

Wenn Du ein SQL Dump erstellst soltest Du IMMER alle relevanten Tabellen sichern. So bleiben auch die Verknüpfungen erhalten.
Alles andere ist nur Flickenschusterei.

Jetzt wirst Du Dich fragen was Dir dieses Posting nützt:
Ganz einfach: Dein Problem existiert nicht wenn Du alle Tabellen "ziehst".

TomIRL

[FrankieB]

Hallo Tom,

Alles andere ist nur Flickenschusterei.

Das behauptest Du ;-)

Jetzt wirst Du Dich fragen was Dir dieses Posting nützt:
Ganz einfach: Dein Problem existiert nicht wenn Du alle Tabellen "ziehst".

Wenn es so einfach wäre, hätte ich bestimmt nicht gefragt. Meine Vorstellung von einem Backup ist, daß ich nicht nur irgendeine Kopie der betroffenen Tabellen wieder herstelle, sondern auch die Änderungen bzw. den Verlust von Daten nachvollziehen kann.

Bei einer Wiederherstellung (die muss ja nicht auf einem Server laufen) würden halt nur die wirklich geänderten/verlorenen Daten wiederhergestellt.

Was ich haben möchte, ist eine Art inkrementales Backup. Ob dieses dann zur Wiederherstellung oder anderen Auswertungen dient, ist letztendlich egal, denn das Prinzip ist das gleiche.

Gruss
frankie

[TomIRL]

Hallo Tom,

Alles andere ist nur Flickenschusterei.

Das behauptest Du ;-)

Ich arbeite lange genug um dies so behaupten zu können :-)

Tabellen "ziehst".

Wenn es so einfach wäre, hätte ich bestimmt nicht gefragt. Meine Vorstellung von einem Backup ist, daß ich nicht nur irgendeine Kopie der betroffenen Tabellen wieder herstelle, sondern auch die Änderungen bzw. den Verlust von Daten nachvollziehen kann.

Ein Backup ist immer ein Abbild eines bestimmten Zustandes.
Du kannst also nur versuchen dei Backupintervalle zu verkürzen.
Z.Bsp automatische Backups via Cronjobs alle Stunden.

Bei einer Wiederherstellung (die muss ja nicht auf einem Server laufen) würden halt nur die wirklich geänderten/verlorenen Daten wiederhergestellt.

Was ich haben möchte, ist eine Art inkrementales Backup. Ob dieses dann zur Wiederherstellung oder anderen Auswertungen dient, ist letztendlich egal, denn das Prinzip ist das gleiche.

Dann mußt Du eine logfile mitschreiben lassen, dass ist ja nicht so schwierig, unter Umständen bietet ja MySql standadmässig eins an weiss ich jetzt nicht so genau...
Und die Logfile reverse "abarbeiten" das kannst Du mit einer Programmiersprache Deiner Wahl machen.

Viele Grüße TomIRL

[Eternius]

Wenn es so einfach wäre, hätte ich bestimmt nicht gefragt. Meine Vorstellung von einem Backup ist, daß ich nicht nur irgendeine Kopie der betroffenen Tabellen wieder herstelle, sondern auch die Änderungen bzw. den Verlust von Daten nachvollziehen kann.

&&

Ein Backup ist immer ein Abbild eines bestimmten Zustandes.

=

das findet sich in dem Begriff Konsistenz einer Datenbank wieder. Es gibt zig systeme die genau hinter diesem problem hinterher sind, und alle ziemlich komplex sind (sicherung und wiederherstellung), wenn dir deine daten so wichtig sind, so könntest du nach jeder transaktion a und danach tranksaktion b, einfach  transaktion a in einer andere (live) datenbank ausführen, die dann einfach deine live datenbank einen schritt hinterherhängt. Ist nichts anderes als das was TomIRL gesagt hat.

ausserdem wenn dir sooft daten abhanden kommen, vielleicht musst du an deinem skript ein bisschen was ändern.

[FrankieB]

Hi,

das findet sich in dem Begriff Konsistenz einer Datenbank wieder.

Meine Datenbank sollte zum Zeitpunktes des Backups und auch sonst konsistent sein. Dazu habe ich bereits ein Tool geschrieben (mit dem man die Konsistenz prüfen kann). Dieses Tool ist aber ziemlich komplex (für mich zumindest) und wollte diesen Aufwand für Backups vermeiden. Daher habe ich mir erlaubt hier im Forum zu fragen, ob nicht eine/r einen besseren Ansatz oder Workaround dazu kennt.

ausserdem wenn dir sooft daten abhanden kommen, vielleicht musst du an deinem skript ein bisschen was ändern.

... bis jetzt sind mir noch niemals Daten abhanden gekommen, ich habe lediglich laut über meine Wunschvorstellung von einem Backup nachgedacht, mehr nicht. Und natürlich habe ich auch schon einiges probiert, ansonsten hätte ich hier nicht gefragt. Vielleicht bleibt meine Idee auch Wunschdenken weil sie auf einem falschen Denkansatz basiert. Auch in diesem Fall würde mir diese Diskussion nützen, da ich mein derzeitiges konzept ändern müsste. Aber bislang habe ich noch keine Antwort bekommen, welche auch begründen kann, warum es nicht geht. Den letzten Satz bitte nicht mißverstehen, ich bin für jede konstruktive Kritik dankbar.

Gruss
Frankie

[Eternius]

ob nicht eine/r einen besseren Ansatz oder Workaround dazu kennt. ich bin für jede konstruktive Kritik dankbar.

ok tatsachen auf den tisch: keine ahnung was einen workaround/Ansatz betrifft ;-) sorry deswegen: halt ich jetzt die klappe

---

[TomIRL]

Also:
In einer halbwegs vernünftigen Datenbank ändern sich IMMER irgndwelche Daten.
Das heist die bisherigen Backupsystem stellen eben irgendwo ein Backup her welches im Fall eines Datenverlustes eingespielt werden kann. Natürlich kann es sein, dass dabei Daten verloren gehen. Das Risiko ist aber überschaubar, weil man sagen kann also alle Änderungen ab Zeitpunkt x müßen wiederholt werden.
das System welches Du bevorzugst müßte komplett vom Netz gehen weil, wenn Du da mit Deinem Backupssystem dranherumwerkelst dann könnte es ja sein, dass vorn die Daten schon wieder geändert werden.
Wie willst Du also dass Problem in den Griff bekommen.
 Das nächste und nicht zu unterschätzende Problem wäre ja Die Fehlerquote die Du einbaust wenn Du manuell (wie willst Du sonst die ID  zuordnen) die daten änderst.
Woher willst Du wissen ob tatsächlich alle betroffenen Datensätze geändert wurden und genau so wieder sind wie sie sein sollten.

Ich will Dir nicht den Mut nehmen, der Ansatz ist verständlich aber völlig praxisfern. Mit Deinem Ansatz schaffst Dui die Voraussetzungen für eine inkonsitente DB.

TomIRL

[FrankieB]

Hallo Tom,

In einer halbwegs vernünftigen Datenbank ändern sich IMMER irgndwelche Daten.

Natürlich, dafür ist die DB ja da ,-)

Das heist die bisherigen Backupsystem stellen eben irgendwo ein Backup her welches im Fall eines Datenverlustes eingespielt werden kann.

Auch klar, ich wollte es eben nur anders lösen.

Das nächste und nicht zu unterschätzende Problem wäre ja Die Fehlerquote die Du einbaust wenn Du manuell (wie willst Du sonst die ID  zuordnen) die daten änderst.

Meine Backupfunktion ist für Benutzer gedacht, welche keinen Zugriff auf die MySQL-Verbindungsdaten oder phpMyAdmin haben.

Woher willst Du wissen ob tatsächlich alle betroffenen Datensätze geändert wurden und genau so wieder sind wie sie sein sollten.

Ich will Dir nicht den Mut nehmen, der Ansatz ist verständlich aber völlig praxisfern. Mit Deinem Ansatz schaffst Dui die Voraussetzungen für eine inkonsitente DB.

Ich werde meine geplante Vorgehensweise überdenken weil ich insbesondere eine inkonsitente DB vermeiden möchte.

Bisher dachte ich, dass ich Inkonsistenzen dadurch vermeiden könnte, indem ich die verknüpften Schlüssel mittels php überprüfe.

Vielen Dank an dich und Eternius für eure Hinweise.

Gruss
Frankie

[Eternius]

insert into table (autoincrementfeld) values ([die id, die aber nicht belegt sein darf/sollte])

funktioniert zumindest bei mir. ausser kraft setzen. hmm. kannst mal bei mysql.de unter dokumentation schauen.

[FrankieB]

Hallo Eternius,

insert into table (autoincrementfeld) values ([die id, die aber nicht belegt sein darf/sollte])

funktioniert zumindest bei mir.

das funktioniert bei mir auch, aber genau um das ging es bei meiner Frage nicht.

Es ging mir darum, ein Feld mit "autoincrement"-Eigenschaft bei Bedarf einen Wert zuzuweisen, der nicht "autoincrement" ist, sondern fest vorgegeben ist. Duplikate gibt es nicht, diese werden programmseitig aufgefangen. Es geht lediglich um's Einfügen an einer bestimmten Position.

ausser kraft setzen. hmm. kannst mal bei mysql.de unter dokumentation schauen.

habe ich schon, und leider nix gefunden, daher habe ich hier gefragt.

Gruss
Frankie

[Eternius]

Es geht lediglich um's Einfügen an einer bestimmten Position.

aha ;-) das einfügen an einer bestimmten zeilenposition in einer datenbank ist völlig irrelevant, da sich die datensätze mit order by id asc/desc immer sortieren lassen.

genausowenig interessieren mich wie meine box die dateien auf der platte speichert, weil ich sie mir sortieren/suchen und entsprechend ausgeben kann.

[FrankieB]

Hi,

genausowenig interessieren mich wie meine box die dateien auf der platte speichert, weil ich sie mir sortieren/suchen und entsprechend ausgeben kann.

natürlich ist das relevant, wenn die ID z.B. den Datensatz eines Kunden darstellt.

Für den Fall id^=KD-nr müssten dann z.B. auch alle Bestellungen, Rechnungen, etc. umgeschrieben werden. Genau das möchte ich vermeiden.

Gruss
Frankie

[ToMIRL]

Hi,

natürlich ist das relevant, wenn die ID z.B. den Datensatz eines Kunden darstellt.

Für den Fall id^=KD-nr müssten dann z.B. auch alle Bestellungen,

Na da kommen wir doch der Sache schon näher..
Die Interne Datenbank ID sollte aus den von Dir genannten Gründen keine andere Funktion haben als Verknüpfung von Tabellen....
Also mache ein zusätzliches Feld mit der Kundennummer.
Das ist übrigens das was ich mit Flickschusterei meinte...
TomIRL

[Harry]

Holladiewaldfee,

natürlich ist das relevant, wenn die ID z.B. den Datensatz eines Kunden darstellt.

Für den Fall id^=KD-nr müssten dann z.B. auch alle Bestellungen, Rechnungen, etc. umgeschrieben werden. Genau das möchte ich vermeiden.

Ja, köpfen wir doch mal ein paar Nägel:

Du hast also eine Tabelle 1:

ID (autoinc.)  |  Blablubb_weiter_daten ...

1                 Max Mustermann, Pfeiffe, wat weiß ich
   2                 Hanna Hanswurst
   7                 Thorsten "Wer hat die 3-6 gelöscht" Maier

usw.

Und ein paar Tabellen, die diese ID mit anderen Daten verknüpft.
Hab ich das soweit richtig verstanden? Ja?

Dann kannst Du doch bei einem Backup die Datensätze mit der richtigen ID wieder einspielen, indem Du diese in der Query explizit angibst, also

INSERT INTO tabelle1 (id, blablubb) VALUES (5, 'Der verlorene Sohn');

MySQL merkt dann schon, daß autoincrement dann fehl am Platz ist und trägt die in der Query angegebene ID ein.

Ciao,

Harry

[FrankieB]

Holladrihöö,

Ja, köpfen wir doch mal ein paar Nägel:

nur zu Waldfee ,-)

Du hast also eine Tabelle 1:

[alles richtig]

MySQL merkt dann schon, daß autoincrement dann fehl am Platz ist und trägt die in der Query angegebene ID ein.

MySQL merkt das und ich habe es sogar auch schon gemerkt.

Danke an Alle & Gruss

Frankiederwaldbär