Wie mit Tabellen-veränderungen umgehen?

Hallo,

ich soll ein System (InnoDB) redesignen und habe z.B. eine Tabelle in
der der Primary Key 'objectName' nicht ein Integer ist, sondern ein md5
hash (Warum weiß ich auch nicht...). Diese wird in mehreren anderen
Tabellen referenziert.
Jetzt möchte ich den Primary Key 'objectName' (VARCHAR) in id (INT
AUTO_INCREMENT) verändern.
Das Problem ist, das die DB mehrere 1000 Einträge hat die auch noch
verlinkt sind.
Gibt es Tools um Datenstrukturen zu bearbeiten und zu verändern oder
wie soll ich dieses Problem lösen?
Viele Grüße,

Nikolai Onken

Re: Wie mit Tabellen-veränderungen umgehen?

Nikolai Onken schrieb:
> Hallo,
>
> ich soll ein System (InnoDB) redesignen und habe z.B. eine Tabelle in
> der der Primary Key 'objectName' nicht ein Integer ist, sondern ein md5
> hash (Warum weiß ich auch nicht...). Diese wird in mehreren anderen
> Tabellen referenziert.
> Jetzt möchte ich den Primary Key 'objectName' (VARCHAR) in id (INT
> AUTO_INCREMENT) verändern.

Das Folgende *ohne* die Dokumentation zu den Statements gelesen zu
haben, keine Garantie also:

ALTER TABLE tabelle DROP PRIMARY KEY;
ALTER TABLE tabelle ADD neue_ID integer unsigned auto_increment;
ALTER TABLE tabelle2 ADD neue_ID integer unsigned;

Mit hinreichend neuer MySQL-Version solltest Du jetzt ein UPDATE für
jede der abhängigen Tabellen formulieren können, das etwa so aussieht:

UPDATE tabelle2, tabelle1 set tabelle2.neue_id=tabelle1.neue_id where
tabelle2.alte_id = tabelle1.neue_id;

Wenn Du das mit allen abhängigen Tabellen erledigt hast, kommt der

ALTER TABLE tabelle PRIMARY KEY neue_ID;
ALTER TABLE tabelle DROP alte_ID;

Und jetzt für die abhängigen Tabellen:

ALTER TABLE tabelle2 DROP PRIMARY KEY;
ALTER TABLE tabelle2 PRIMARY_KEY neue_ID;

Allerdings solltest Du das DROP alte_ID nur durchführen, wenn Du statt
'warum, weiß ich auch nicht' eine bessere Erklärung für die Existenz
dieses Attributs hast.

Re: Wie mit Tabellen-veränderungen umgehen?

Hey Christian,

danke für deine Antwort!
es gibt keinen speziellen Grund warum der alte Primary Key ein MD5 hash
ist. Dieser Key wird nur in anderen Tabellen referenziert...
Kennst du Tools die diese Migrationen unterstützen? Also in InnoDB
Tabellen den Primary Key von VARCHAR(51) in INT AUTO_INCREMENT zu
verändern?
Viele Grüße,

Nikolai

Re: Wie mit Tabellen-veränderungen umgehen?

Nikolai Onken schrieb:
> Hey Christian,
>
> danke für deine Antwort!
> es gibt keinen speziellen Grund warum der alte Primary Key ein MD5 hash
> ist. Dieser Key wird nur in anderen Tabellen referenziert...
> Kennst du Tools die diese Migrationen unterstützen? Also in InnoDB
> Tabellen den Primary Key von VARCHAR(51) in INT AUTO_INCREMENT zu
> verändern?


Christian hat dir doch alle Statements welche du im MySQL-Client (das
wäre ein Tool) absetzen musst. Er hat also deine Arbeit zur Hälfte
erledigt :)

Überprüfe die SQL-Statements, mache ein Backup und dann ran an die Arbeit.

Grüße

Dirk

Re: Wie mit Tabellen-veränderungen umgehen?

Nikolai Onken schrieb:
> Hey Christian,
>
> danke für deine Antwort!
> es gibt keinen speziellen Grund warum der alte Primary Key ein MD5 hash
> ist. Dieser Key wird nur in anderen Tabellen referenziert...
> Kennst du Tools die diese Migrationen unterstützen? Also in InnoDB
> Tabellen den Primary Key von VARCHAR(51) in INT AUTO_INCREMENT zu
> verändern?

Was an meiner Antwort hast Du nicht verstanden, bzw. was daran sieht
aus wie etwas, wofür man ein "Tool" außer den eigenen zehn Fingern
bräuchte?

Re: Wie mit Tabellen-veränderungen umgehen?

Deine Antwort habe ich verstanden - habe nicht gesagt das irgendwas
unklar ist... Ich frage mich nur ob es nicht ein Tool gibt was das
übernimmt? Wass wenn ich 700 Tabellen habe mit mehrfachen foreign
keys? Es gibt ja auch nicht umsonst z.B. den DBDesigner - man kann
natürlich auch ohne!
Danke trotzdem für die Hilfe,

Nikolai

Re: Wie mit Tabellen-veränderungen umgehen?

Nikolai Onken schrieb:
> Deine Antwort habe ich verstanden - habe nicht gesagt das irgendwas
> unklar ist... Ich frage mich nur ob es nicht ein Tool gibt was das
> übernimmt? Wass wenn ich 700 Tabellen habe mit mehrfachen foreign
> keys? Es gibt ja auch nicht umsonst z.B. den DBDesigner - man kann
> natürlich auch ohne!

Perl? PHP? Python? Ruby? Bash/zsh/tcsh/ksh?

DBDesigner war ein Klicki-Bunti-Tool, sowas eignet sich wohl kaum zum
automagischen Ändern. Wenn Du 5.x benutzt, kannst Du Information
Schema verwenden, um die Namen der betroffenen Tabellen herauszufinden
(Näheres gab's gerade bei planetmysql.org).

Aber ein 'Tool' im Sinne von 'Gui' um 700 Tabellen zu ändern - das
halte ich für albern. Den Code für den Kram kannst Du Dir mit einem
*kurzen* Script ziemlich schnell generieren.

Re: Wie mit Tabellen-veränderungen umgehen?

Christian Kirsch wrote:
> Nikolai Onken schrieb:

>> Kennst du Tools die diese Migrationen unterstützen? Also in InnoDB
>> Tabellen den Primary Key von VARCHAR(51) in INT AUTO_INCREMENT zu
>> verändern?
>
> Was an meiner Antwort hast Du nicht verstanden, bzw. was daran sieht
> aus wie etwas, wofür man ein "Tool" außer den eigenen zehn Fingern
> bräuchte?

:-)

Ich mach das ja nur ungern, aber hier muß ich Nikolai
mal in Schutz nehmen. Um eine Aufgabe wie die von ihm
beschriebene durchzuführen, wäre es enorm hilfreich,
die expliziten (und impliziten) Relationen in der
Datenbank zu kennen. Diese Informationen würde man am
ehesten in einem Designtool a'la DB-Designer vermuten.

Da der Aufwand für die Änderung etwa quadratisch mit
der Anzahl Tabellen steigt, ist die manuelle Variante
u.U. keine sinnvolle Lösung.

Automatisierung funktioniert auch nur, wenn wirklich
alle Relationen in Form von FOREIGN KEY constraints
abgebildet wurden. Außerdem erfordert das einen DBA
mit Programmierfähigkeiten.


Also Nikolai: AFAIK gibt es kein Tool für dein Problem.
Ohnehin würde dir ein solches auch nur nützen, wenn die
logische Struktur deiner Datenbank darin bereits mal
jemand eingegeben hätte. Erraten kann die ein Tool
genausogut (oder schlecht) wie du. Wenn dein Problem
klein genug ist, mach es von Hand. Sonst wirst du um
etwas angewandte (Perl, Ruby, PHP, Java)-Magie wohl
nicht herumkommen.

PS: und erschlag den DBA, der das eingeführt hat ;-)
Ein PK über VARCHAR(51) in InnoDB ist böse!


XL

Re: Wie mit Tabellen-veränderungen umgehen?

Danke Axel - Dann komme ich wohl nicht an Scripting Magie vorbei :)
Das Scrpit denke ich wird jedoch keineswegs kurz, es gibt viel zu viele
Relationen die ich berüksichtigen muss....

Re: Wie mit Tabellen-veränderungenumgehen?

On Thu, 09 Feb 2006 04:47:02 -0800, Nikolai Onken wrote:

> ich soll ein System (InnoDB) redesignen und habe z.B. eine Tabelle in der
> der Primary Key 'objectName' nicht ein Integer ist, sondern ein md5 hash
> (Warum weiß ich auch nicht...). Diese wird in mehreren anderen Tabellen
> referenziert.

Warum willst Du das ändern?

Gruß,
Joachim

--
Warnung: \" kann Augenkrebs verursachen.

Re: Wie mit Tabellen-veränderungenumgehen?

On Thu, 09 Feb 2006 04:47:02 -0800, Nikolai Onken wrote:

> sondern ein md5 hash
> (Warum weiß ich auch nicht...).

Der Grund ist wahrscheinlich, das es nicht ratbar sein soll, weil es
z.Bsp. in URLs verwendet wird/wurde.

Gruß,
Joachim

--
Warnung: \" kann Augenkrebs verursachen.

Re: Wie mit Tabellen-veränderungen umgehen?

Ich wollte es verändern weil der Primary Key VARCHAR 51 Zeichen lang
war. Das würde mich bei der Anzahl von Foreign Keys beschränken da
InnoDB soweit ich weiß nur bis zu eine Länge von 1024 zulässt.
Ansonsten fand ich es unlogisch Felder wie z.B. z.b. Kundennummer,
Rechnungsnummer, etc. als seperate AUTO_INCREMENT hinzuzufügen...
Ansonsten kann ich auch nachvollziehen MD5 keys zu benutzen aber ich
glaube ich bevorzuge IDs...
Viele Grüße,

Nikolai

Re: Wie mit Tabellen-veränderungen umgehen?

Nikolai Onken schrieb:

> Hey Christian,
>
> danke für deine Antwort!
> es gibt keinen speziellen Grund warum der alte Primary Key ein MD5 hash
> ist. Dieser Key wird nur in anderen Tabellen referenziert...

Bist du Dir auch 100% sicher das dieser Hash nicht eine
Sicherheitsfunktion erfüllt? Die z.B. vor solchen Sachen schützt:
http://www.ccc.de/t-hack/
Dann würde ich den PK auf eine Autoinc-Spalte verschieben. Aber nach
draußen hin trotzdem mit dem Hash weiter arbeiten!

> Kennst du Tools die diese Migrationen unterstützen? Also in InnoDB
> Tabellen den Primary Key von VARCHAR(51) in INT AUTO_INCREMENT zu
> verändern?

So was gibt es nicht! Ist auch viel zu speziell. Warum sollte man das
auch haben? Im Idealfall weiß der Designer was er macht. Und wenn nicht,
dann ist die Datenbank meist eh so Kaputt, das so ein Tool auch nix mehr
ausrichten kann!

Re: =?iso-8859-1?q?Re:_Wie_mit_Tabellen-veränderungen_umgehen=3F?

"Nikolai Onken" wrote:

> Ich wollte es verändern weil der Primary Key VARCHAR 51 Zeichen lang
> war. Das würde mich bei der Anzahl von Foreign Keys beschränken da
> InnoDB soweit ich weiß nur bis zu eine Länge von 1024 zulässt.
> Ansonsten fand ich es unlogisch Felder wie z.B. z.b. Kundennummer,
> Rechnungsnummer, etc. als seperate AUTO_INCREMENT hinzuzufügen...
> Ansonsten kann ich auch nachvollziehen MD5 keys zu benutzen aber ich
> glaube ich bevorzuge IDs...

Der richtige Weg ist ganz klar: nach innen mit IDs, nach außen mit
dem nicht erratbaren MD5-Hash.

In InndoDB sollte man keine langen PKs verwenden, weil InnoDB sekundäre
Indexe als Verweis auf den PK ablegt. Es gibt also einmal den Baum mit
den Rows selber und dem PK als Ordnungselement. Für jeden sekundären
Index gibt es einen weiteren Baum mit dem PK der Row und der Indexspalte
als Ordnungselement. Dito bei foreign keys. Ein PK wie VARCHAR(51) wird
also in jedem sekundären Index immer wieder aufgeführt. Das frißt Platz
und braucht Zeit.


XL

Re: =?iso-8859-1?q?Re:_Wie_mit_Tabellen-veränderungen_umgehen=3F?

Ist das so wie du es machst? Encryptest du die indizies nach außen?
Und decryptest sie nach innen?

Re: Re: =?iso-8859-1?q?Re:_Wie_mit_Tabellen-veränderungen_umgehen=3F?

"Nikolai Onken" wrote:
> Ist das so wie du es machst? Encryptest du die indizies nach außen?
> Und decryptest sie nach innen?

Man *kann* das so machen. Wenn man aus Sicherheitsgründen keine IDs
von internen Objekte nach draußen geben will, kann man sie mit Hashes
verschleiern. Das schützt aber nicht gegen Replay-Angriffe. Besser
ist es, Proxy-Objekte zu erzeugen und die an die Nutzersession zu
binden. Also etwa so:

Nutzer hat: Session-ID, Proxy-ID
Webserver: Session-ID -> Session
\ _ Proxy1
Proxy-ID -----> |_ Proxy2 --> reale Objekt-ID
|_ Proxy3

XL

Re: =?iso-8859-1?q?Re:_Wie_mit_Tabellen-veränderungen_umgehen=3F?

Hey Axel,

danke für deine Antwort! Kennst du Webseiten in denen dieses Thema
erklärt wird? Soll ich mir mal Proxy Patterns anschauen?
Viele Grüße,

Nikolai