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