Suche

[tequila]

Hey Leute.
Folgendes Problem. Bin gerade am grübeln, wie ich das am geschicktesten mache die alten Forumsdaten in die neue DB zu bekommen. Es ist ja theoretisch ganz einfach, die alte DB auszulesen und in die neue einzuspielen. Ratz, fatz sind die Daten kopiert aber: nicht ein einziger beschissener Link innerhalb der alten Topics und Posts würde mehr richtig gehen (zumindestens nicht mehr mit Garantie).

Und warum? Die Topic-ID und Post-ID sind nunmal "autoincrement" Werte, die UniqueID eines Topics bzw. Posts. Und wenn ich den alten Inhalt in die neue DB einlesen würde, KÖNNTE ICH DIE NICHT ÜBERGEBEN
Die DB zählt ja selber hoch.

Jetzt meine Frage: hat einer von Euch Erfahrungen mit dieser "ALTER"-SQL-Kram? Ist es da theoretisch möglich von der alten DB IN DER MITTE und kunterbund (auf die alte DB bezogen) Spalten in Tabellen zu löschen, verändern, umbenennen und ergänzen? Mein Wissen beschränkt sich darauf das ich weis, das ich damit den Typ von Tabellen und Zeilen ändern kann, auch den Namen. Aber kann ich damit wirklich aus der "alten DB-Struktur" die "neue" DB-Struktur erzeugen?

Bin über alles seeeehr dankbar was hilfreich ist, die alten Daten in die neue DB zu bekommen (stellt Euch nur mal vor hier bei maax-design würde kein einziger Topic-Link mehr in den Posts gehen .... oh Gott!).

Kurze Erklärung noch eh einer anfängt darüber nachzudenken: das kopieren der alten Daten würde so lange gut gehen und auch mit der richtigen ID (so lange ich in der neuen DB noch keinen Eintrag gemacht habe und es sozusagen bei "1" losgeht), bis eine Stelle erreicht ist, wo mal ein Topic/Beitrag gelöscht wurde. Und danach stimmt nichts mehr. Denn die ID wird nicht mehr neu vergeben, es ist dann dort ein "Loch" und genau ab jetzt stimmen die IDs des neuen und des alten Forums nicht mehr überein

[tequila]

Da fällt mir gerade auf:

Ich habe nichts an der Tabelle Threads und Posts geändert, diese Struktur kann also bleiben

Bei der Forumstabelle kommt nur eine Spalte dazu, die Member-Tabelle umzuwurschteln dürfte ja nun gar kein Hit sein, denn da werden keine IDs von benutzt ... also: scheint sich erledigt zu haben

Den mit diesem "ALTER"-Krims bekomme ich die eine Spalte an die Foren-Tabelle ran, Members kann ich Kopieren und dann löschen und die anderen Tabellen auch.

OK, wahr wohl falscher Alarm bzw. Alex hat nicht lange genug darüber nachgedacht

[Robert1968]

wie wärs wenn du nur die alten einträge einfach umbenennst und dann noch das neue mit alter hinzufügst?
wäre wohl am einfachsten
bzw wenn man nicht umbenennen kann eine sicherung ziehen und die sicherung umbenennen
das wäre aber keine saubere Lösung denke ich

[Robert1968]

hier sind die befehle für das rename + DB sicherung:

RENAME TABLE tbl_name TO new_tbl_name[, tbl_name2 TO new_tbl_name2,...]

The rename is done atomically, which means that no other thread can access any of the tables while the rename is running. This makes it possible to replace a table with an empty one:

CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;

The rename is done from left to right, which means that if you want to swap two tables names, you have to:

RENAME TABLE old_table    TO backup_table,
             new_table    TO old_table,
             backup_table TO new_table;

As long as two databases are on the same disk you can also rename from one database to another:

RENAME TABLE current_db.tbl_name TO other_db.tbl_name;

When you execute RENAME, you can't have any locked tables or active transactions. You must also have the alter and drop privileges on the original table, and the create and insert privileges on the new table.

If MySQL encounters any errors in a multiple-table rename, it will do a reverse rename for all renamed tables to get everything back to the original state.

[tequila]

Jup, danke erst einmal. Hab mir gerade das Manual von MySQL gesaugt und mit dem ALTER-Kram bekommt man wirklich alles hin, was der phpMyAdmin auch kann (wie sollte er es denn sonst auch machen ?!?), daher sollte das alles kein Thema sein. WErde die alte DB einfach umstricken und gut ist

[Andi]

Hi Alex,

wenn in der Anfügeabfrage der alte autoincrement-Feld-Wert mit übergeben wird, wird dieser gleiche Wert auch in der neuen Tabelle abgespeichert.
Also kein Problem!
Probleme gibt es nur, wenn in der neuen Tabelle bereits Datensätze vorhanden sind.

[tequila]

He, he, he ... hab das Script fertig und es konvertiert wunderbar

Wenn Frank aus den Puschen kommt und mir (endlich!!!) den Table-Dump des Forums hier zuschickt, dann werde ich es mal im "großen Stil" probieren. Lokal mit meinen 250-Foren hat es funktioniert. Sind halt nur kaum Topics drinnen

Außerdem habe ich gleich erweiter *LOL*
Da ging ja keine Zahl, die wichtig ist, über 999999. So, nun nimm mal so eine Gamer-Site wie DarkBoy sie hat. Unter 1 Mio Posts bzw Antworten? Das raucht die doch in 6 Monaten wech. Also alles auf 7-Stellig gesetzt (man muß ja auch nicht übertreiben und mit dem Speicher asen )

Nun denn, kannst Du auch einen Table-Dump ziehen von hier?

Ciao Alex

[JensWagenknecht]

@Tequila Du machst das schon richtig.

Aber einen heißen Tip hätte ich schon.

Sichere erst einmal per SQL die "alten Tabellen", dannach einfach die Tabellen umstricken.
Ist ja kein Problem. Aber Frage um gottes willen die Fehler ab. d.h. geht was nicht, so muß er das irgendwo ausgeben um da weiter machen zu können. wie gesagt eine heiße Sache.

Zu 10% mußt Du davon ausgehen das es schief geht. Also, die alten tabellen "sichern" (kopieren in neue alte).
Und zähle mal eine Variabel mit hoch bei jedem Schritt, sow eist Du wo er aufgehört hatte.

Bei Access hatte ich für so etwas Programmieren immer eine ganzen tag gebraucht und s hatte schon einmal meine  **UPS** gerettet bei 4000 Kunden.

Gruß Jens