DB-Export mit Constraints
DB-Export mit Constraints
am 06.05.2006 13:57:56 von Ralph Stahl
Moin,
Wenn ich eine mysql-DB mit foreign keys bzw. constraints mittels=20
mysqldump (Shell), phpMyAdmin oder so einem Tool exportiere, ist zwar=20
alles da, aber in der falschen Reihenfolge (alphabetisch). Heißt, beim=20
Zurückspielen stimmen die Constraints nicht und der Import geht in die=20
Hose.
Ich habe das eben mit einigen Tools probiert und mußte die Tabellen zu=20
Fuß umsortieren, damit der Import geht. Bei 20 Tabellen geht das noch,=20
bei richtig vielen wohl eher nicht.
Wie kann ich das sinnvoll machen? Sicher kann ich pro Tabelle ALTER=20
TABLE ... DISABLE KEYS schreiben, und hinter her eben ALTER TABLE ...=20
ENABLE KEYS. Aber eben wieder pro Tabelle. Läßt sich das generell etwa=
=20
mit SET FOREIGN_KEY_CHECKS=3D0 (und danach =3D1) machen?
Blöd ist die Handarbeit vor allem insofern, als es mir um Backup und =20
Recovery von ggf. um die 100 Tabellen geht, die auch ein "unbedarfter"=20
per Knopfdruck (php-Seite) machen kann, ohne irgendwie am SQL-Script=20
drehen zu müssen. "Knopfdruck" kann auch heißen, nach Beschreibung=20
phpMyAdmin oder mySQLdumper anzuschieben und das downgeloadete File=20
einfach zu archivieren.
Sicher geht das irgendwie elegant, aber ich finde es nicht.
Ralph
Re: DB-Export mit Constraints
am 06.05.2006 14:28:33 von Kai Ruhnau
Ralph Stahl wrote:
> Wenn ich eine mysql-DB mit foreign keys bzw. constraints mittels
> mysqldump (Shell), phpMyAdmin oder so einem Tool exportiere, ist zwar
> alles da, aber in der falschen Reihenfolge (alphabetisch). Heißt, beim
> Zurückspielen stimmen die Constraints nicht und der Import geht in die
> Hose.
Da der zugrunde liegende, gerichtete Graph der Referenzen in einer
relationalen Datenbank üblicherweise nicht kreisfrei ist, gibt es keine
definierte Reihenfolge der Tabellen, wenn man sie wieder einspielen möchte.
> Ich habe das eben mit einigen Tools probiert und mußte die Tabellen zu
> Fuß umsortieren, damit der Import geht. Bei 20 Tabellen geht das noch,
> bei richtig vielen wohl eher nicht.
Das heißt, dass dein manuelles Umsortieren überhaupt funktioniert, ist
Zufall bzw. liegt am einfachen Modell.
> Wie kann ich das sinnvoll machen? Sicher kann ich pro Tabelle ALTER
> TABLE ... DISABLE KEYS schreiben, und hinter her eben ALTER TABLE ...
> ENABLE KEYS. Aber eben wieder pro Tabelle. Läßt sich das generell etwa
> mit SET FOREIGN_KEY_CHECKS=0 (und danach =1) machen?
Wenn ich hier ein Dump mit mysqldump erstelle befindet sich am Anfang
der Datei folgende Zeile:
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0 */;
Will sagen: Seit Version 4.0.14 beherrscht MySQL genau das, was du
brauchst und setzt es auch so um (beim mysqldump von 4.0.x muss man
wahrscheinlich noch --opt manuell angeben, ab 4.1 ist das der Default)
Ob das Administrationsspielzeug phpMyAdmin das kann, möchte ich fast
bezweifeln.
[snip]
> Sicher geht das irgendwie elegant, aber ich finde es nicht.
> Ralph
Welche Version setzt du ein, welche Kommandozeile benutzt du für den
Aufruf von mysqldump?
Grüße
Kai
--
This signature is left as an exercise for the reader.
Re: DB-Export mit Constraints
am 06.05.2006 14:34:57 von Axel Schwenke
Ralph Stahl wrote:
> Läßt sich das generell etwa
> mit SET FOREIGN_KEY_CHECKS=0 (und danach =1) machen?
Warum schaust du nicht einfach mal ins Handbuch?
Qvr Nagjbeg vfg: Wn, fb znpug zna qnf. Haq uvaervpuraq arhr
Irefvbara iba zlfdyqhzc znpura qnf fbtne fgnaqneqzäßvt fb.
XL
Re: DB-Export mit Constraints
am 08.05.2006 18:09:51 von Ralph Stahl
Kai Ruhnau schrieb:
> Ralph Stahl wrote:
>> Wenn ich eine mysql-DB mit foreign keys bzw. constraints mittels
>> mysqldump (Shell), phpMyAdmin oder so einem Tool exportiere, ist zwar
>> alles da, aber in der falschen Reihenfolge (alphabetisch). Heißt, beim
>> Zurückspielen stimmen die Constraints nicht und der Import geht in die
>> Hose.
>
> Da der zugrunde liegende, gerichtete Graph der Referenzen in einer
> relationalen Datenbank üblicherweise nicht kreisfrei ist, gibt es keine
> definierte Reihenfolge der Tabellen, wenn man sie wieder einspielen möchte.
Das ist korrekt, in meinem Fall würde es aber gehen.
>
>> Ich habe das eben mit einigen Tools probiert und mußte die Tabellen zu
>> Fuß umsortieren, damit der Import geht. Bei 20 Tabellen geht das noch,
>> bei richtig vielen wohl eher nicht.
>
> Das heißt, dass dein manuelles Umsortieren überhaupt funktioniert, ist
> Zufall bzw. liegt am einfachen Modell.
Es ist einfach genug in diesem Fall.
>
>> Wie kann ich das sinnvoll machen? Sicher kann ich pro Tabelle ALTER
>> TABLE ... DISABLE KEYS schreiben, und hinter her eben ALTER TABLE ...
>> ENABLE KEYS. Aber eben wieder pro Tabelle. Läßt sich das generell etwa
>> mit SET FOREIGN_KEY_CHECKS=0 (und danach =1) machen?
>
> Wenn ich hier ein Dump mit mysqldump erstelle befindet sich am Anfang
> der Datei folgende Zeile:
>
> /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
> FOREIGN_KEY_CHECKS=0 */;
Aha, also müßte ich beim Einspielen diese Zeilen ent-kommetieren? Bzw.
es sollte ja dann wohl mit "mysql datenbank < datensicherung.sql"
automatisch erkannt werden!?
>
> Will sagen: Seit Version 4.0.14 beherrscht MySQL genau das, was du
> brauchst und setzt es auch so um (beim mysqldump von 4.0.x muss man
> wahrscheinlich noch --opt manuell angeben, ab 4.1 ist das der Default)
>
> Ob das Administrationsspielzeug phpMyAdmin das kann, möchte ich fast
> bezweifeln.
Du zweifelst zu Recht. Das ist insofern blöd, als bei Web-Providern
phpMyAdmin oft mangels Shell-Zugang die einzige Möglichkeit ist. Aber
ich kann die Zeilen ohne Kommentar ja dann zu Fuß davorsetzen.
[...]
> Welche Version setzt du ein, welche Kommandozeile benutzt du für den
> Aufruf von mysqldump?
mysqldump datenbank > datenbank.sql, Version 5.0.
> Kai
Danke Dir!
Ralph
Re: DB-Export mit Constraints
am 08.05.2006 18:12:52 von Ralph Stahl
Axel Schwenke schrieb:
> Ralph Stahl wrote:
>
>> Läßt sich das generell etwa
>> mit SET FOREIGN_KEY_CHECKS=0 (und danach =1) machen?
>
> Warum schaust du nicht einfach mal ins Handbuch?
[andiestirnklatsch] warum bin ich da nicht gleich drauf gekommen!?
Vielleicht, weil ich es überlesen oder nicht gefunden oder nicht
verstanden habe? Deswegen frage ich ja hier.
>
> Qvr Nagjbeg vfg: Wn, fb znpug zna qnf. Haq uvaervpuraq arhr
> Irefvbara iba zlfdyqhzc znpura qnf fbtne fgnaqneqzäßvt fb.
So ist es. In dr Krze lgt d Wrze.
Trotzdem danke, ich werde mich bessern,
Ralph
Re: DB-Export mit Constraints
am 09.05.2006 00:34:54 von Kai Ruhnau
Ralph Stahl wrote:
> Kai Ruhnau schrieb:
>> Wenn ich hier ein Dump mit mysqldump erstelle befindet sich am Anfang
>> der Datei folgende Zeile:
>>
>> /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
>> FOREIGN_KEY_CHECKS=0 */;
>
> Aha, also müßte ich beim Einspielen diese Zeilen ent-kommetieren? Bzw.
> es sollte ja dann wohl mit "mysql datenbank < datensicherung.sql"
> automatisch erkannt werden!?
Ja, es wird automatisch erkannt.
Wenn der MySQL-Client diesen Dump einliest, behandelt er Kommentare der
Form /*!xxxxx ... */ besonders. Wenn die Ziel-MySQL-Version größer ist,
als x.xx.xx, dann wird der Teil in den Kommentaren ausgeführt,
anderenfalls ignoriert. So werden neuere Features (auch innerhalb eines
Major Release) kompatibel im Dump untergebracht.
Grüße
Kai
--
This signature is left as an exercise for the reader.
Re: DB-Export mit Constraints
am 09.05.2006 12:17:09 von Ralph Stahl
In schrieb=20
kai.newsgroup@tragetaschen.dyndns.org:
> Ralph Stahl wrote:
> > Kai Ruhnau schrieb:
> >> Wenn ich hier ein Dump mit mysqldump erstelle befindet sich am Anfang=
=20
> >> der Datei folgende Zeile:
> >>
> >> /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=3D@@FOREIGN_KEY_CHECKS,=20
> >> FOREIGN_KEY_CHECKS=3D0 */;
> >=20
> > Aha, also müßte ich beim Einspielen diese Zeilen ent-kommetieren? B=
zw.=20
> > es sollte ja dann wohl mit "mysql datenbank < datensicherung.sql"=20
> > automatisch erkannt werden!?
>=20
> Ja, es wird automatisch erkannt.
>=20
> Wenn der MySQL-Client diesen Dump einliest, behandelt er Kommentare der=
=20
> Form /*!xxxxx ... */ besonders. Wenn die Ziel-MySQL-Version größer is=
t,=20
> als x.xx.xx, dann wird der Teil in den Kommentaren ausgeführt,=20
> anderenfalls ignoriert. So werden neuere Features (auch innerhalb eines=
=20
> Major Release) kompatibel im Dump untergebracht.
>=20
> Grüße
> Kai
>=20
>=20
Danke Dir, Du hast mir sehr geholfen :-).
Ralph