Wie Strukturen mehrerer Datenbanken identisch halten?

Hallo,

ich habe eine kleine Anwendung geschrieben (php), für die ich MySql=20
verwende. Diese Anwendung wird von mittlerweile 12 kleineren Firmen=20
genutzt. Entsprechend häufig gibt es auch 12 Datenbanken "eigentlich"=20
identischer Struktur auf meinem MySql-Server.

Diese Anwendung entwickel ich ständig weiter, was manchmal auch=20
Änderungen am Datenbankdesign (derzeit 17 Tabellen) erfordert. Nun=20
habe ich das Problem, daß die Struktur in allen 12 Datenbanken völlig=20
identisch sein muß. Dazu gibt es noch Tabellen mit =20
"Pflichteinträgen", die zumindest in einigen Feldern ebenfalls über=20
alle Datenbanken hinweg identisch sein müssen.

Bisher nehme ich die Änderungen in Datenbanken manuell vor. Das ist=20
aber sehr zeitaufwendung und führt bei mir leider auch immer wieder zu=20
Fehlern, weil diese stupide Tätigkeit mir den letzten Nerv raubt und=20
deshalb fast automatisch zu Flüchtigkeitsfehlern führt. Das Problem=20
vergrößert sich wahrscheinlich auch noch, weil ich nicht unbegründete=
r=20
Hoffung bin, die Anwendung noch weiter unter das Volk zu bringen ;-)

Ich suche deshalb ein schnelles und sicheres Verfahren, die=20
Datenbankstrukturen und am Besten auch die Pflichteinträge in allen=20
derzeit 12 Datenbanken identisch zu halten. Habt Ihr Ideen, wie ich=20
dieses Problem am Besten löse?

Viele Grüße

Frank Dell

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Hallo,

franko.dello@googlemail.com wrote:
>
> Ich suche deshalb ein schnelles und sicheres Verfahren, die
> Datenbankstrukturen und am Besten auch die Pflichteinträge in allen
> derzeit 12 Datenbanken identisch zu halten. Habt Ihr Ideen, wie ich
> dieses Problem am Besten löse?

oh, ganz einfach: Jede Änderung, die propagiert werden muss, zieht einen
Versionswechsel deiner Anwendung nach sich. Für jede Version gibt es
eine Datei, in der die Datenbankänderungen als SQL Anweisungen ausgehend
von der vorherigen Version abgebildet sind.

Updatest du jetzt eine Version, führst du bloss alle Update Dateien vom
letzten Stand bis zum aktuellen Stand der zu installierenden Version aus.

Dieser Schritt lässt sich sogar bequem automatisieren.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Heidiho,
*franko.dello@googlemail.com* schrub:
> Ich suche deshalb ein schnelles und sicheres Verfahren, die
> Datenbankstrukturen und am Besten auch die Pflichteinträge in allen
> derzeit 12 Datenbanken identisch zu halten. Habt Ihr Ideen, wie ich
> dieses Problem am Besten löse?

Wie Andreas schon schrieb, ist das nicht zu kompliziert. Das phpBB
macht das so: In einer Tabelle mit zig Konfigurationswerten wird auch
die aktuelle Versionsnummer gespeichert. Bei einem Update der Software
muss auch ein PHP-Script aufgerufen werden, das diese Nummer ausliest
und dann alle Queries zum ändern der Tabellen aufruft, die nötig sind
sie auf den aktuellen Stand zu bringen - denn nichts anderes als eine
Ausführung von Queries machst du ja beim Ändern der Strukturen. Das
kann so weit gehen, dass du in diesem Script nicht nur immer die
aktuellsten Änderungen von einer bis zur nächsten Version in Queryform
speicherst, sondern auch größere Versionssprünge zulässt.
mfg
Nico

--
www.buchtips.net - Rezensionen online

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Hallo Andreas, hallo Nico,

ich glaube mit Eurem Vorschlag kann ich mich anfreuden. Zur konkreten=20
Umsetzung würde ich mich gerne von ein oder zwei Scripten inspirieren=20
lassen, die eine solche Aufgabenstellung lösen. Habt Ihr ne Idee wo=20
ich sowas finde? (So ein Monster wie phpBB würde ich aber nur ungern=20
installieren wollen)

Danke und viele Grüße

Frank Dell

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Hallo,

franko.dello@googlemail.com wrote:
>
> ich glaube mit Eurem Vorschlag kann ich mich anfreuden. Zur konkreten
> Umsetzung würde ich mich gerne von ein oder zwei Scripten inspirieren
> lassen, die eine solche Aufgabenstellung lösen. Habt Ihr ne Idee wo
> ich sowas finde? (So ein Monster wie phpBB würde ich aber nur ungern
> installieren wollen)

phpBB ist nicht die einzige Anwendung, die so etwas nutzt. Diverse, vor
allem webbasierte Projekte nutzen diesen Mechanismus. Serendipity
fällt mir da aus dem Stehgreif ein.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Hallo!

Auch wenn schon eine recht gute Lösung genannt wurde möchte ich doch
noch "als Anregung" eine Methode anbringen die ich bei einem
Delphi-Framework gesehen und eingesetzt habe.

Die aktuelle DB-Struktur lag dort in XML-Form vor. Es gab ein Tool
welches diese Struktur mit der tatsächlichen in der DB verglichen hat.
Bei Unterschieden wurde dann die DB-Struktur auf den Stand der XML-Datei
gebracht. Kam es dabei zu Konflikten gab es ne Meldung.
Dasselbe Prinzip gab es auch für Stammdaten. Dafür gab es auch eine
XML-Datei die abgeglichen wurde. Woran ich mich nicht mehr genau
erinnere ist ob es auch Lösch-Kennzeichen für die Daten gab, ich meine
aber nein.

Diese Lösung ist sicher komplizierter zu implementieren, könnte aber
ggfs. flexibler sein, weil man sich nicht mehr Gedanken machen muss
welche Version der Kunde gerade hat um ggfs. mehrere Dateien einzuspielen.

Nur mal so als Anregung...

MfG Thomas.

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

Borsdorf, Thomas wrote:
>
> Die aktuelle DB-Struktur lag dort in XML-Form vor. Es gab ein Tool
> welches diese Struktur mit der tatsächlichen in der DB verglichen hat.
> Bei Unterschieden wurde dann die DB-Struktur auf den Stand der XML-Datei
> gebracht. Kam es dabei zu Konflikten gab es ne Meldung.
> Dasselbe Prinzip gab es auch für Stammdaten. Dafür gab es auch eine
> XML-Datei die abgeglichen wurde. Woran ich mich nicht mehr genau
> erinnere ist ob es auch Lösch-Kennzeichen für die Daten gab, ich meine
> aber nein.

Man kann Probleme sicherlich auf viele Arten erschlagen, das hier hört sich
aber besonders arbeitsintensiv an für mich.

- es gibt keine Dokumentation, was sich von Release zu Release geändert
hat oder diese Information muss extern dokumentiert werden -> wer macht
das freiwillig?
- wer schreibt einen Parser, um die aktuelle Struktur der DB herauszufinden?
- wie sorgt das Update dafür, das Änderungen in der richtigen Reihenfolge
ausgeführt werden? Wie kann das Tool überhaupt erkennen, welche Spalten
es z.B. zuerst addieren müsste, weil anderswo ein FK auf diese Spalte
dazukommt?
- Ungewöhnlicher Fall: was passiert be inkompatiblen Änderungen, die nicht
mit einem ALTER TABLE zu lösen wären oder die vorher Änderungen an den
Daten benötigen?
- Wieso wird XML als Antwort auf alle Probleme genutzt und welchen
effektiven Vorteil bietet die XML Struktur?


> Diese Lösung ist sicher komplizierter zu implementieren, könnte aber
> ggfs. flexibler sein, weil man sich nicht mehr Gedanken machen muss
> welche Version der Kunde gerade hat um ggfs. mehrere Dateien einzuspielen.

Ich sehe hier keine Flexibilität, ausser dem Buzzwordfaktor.
Zu dem Haufen Arbeit, der mir da oben dazu auf den ersten Blick eingefallen
ist, kommt aber sicherlich noch einiges hinzu, wenn man das konkret
implementieren möchte.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wie Strukturen mehrerer Datenbanken identisch halten?

"Borsdorf, Thomas" wrote:
>
> Auch wenn schon eine recht gute Lösung genannt wurde möchte ich doch
> noch "als Anregung" eine Methode anbringen die ich bei einem
> Delphi-Framework gesehen und eingesetzt habe.
>
> Die aktuelle DB-Struktur lag dort in XML-Form vor. Es gab ein Tool
> welches diese Struktur mit der tatsächlichen in der DB verglichen hat.
> Bei Unterschieden wurde dann die DB-Struktur auf den Stand der XML-Datei
> gebracht. Kam es dabei zu Konflikten gab es ne Meldung.
....

> Diese Lösung ist sicher komplizierter zu implementieren, könnte aber
> ggfs. flexibler sein,

Flexibler? Im Gegenteil! IMHO ist das ein typischer Fall von Buzzword-
Compliance. Warum einfach, wenn man auch XML dafür nehmen kann!1!elf

Das Problem ist, daß sich allein aus dem Istzustand und dem Zielzustand
des Datenbank-Schemas kein eindeutiger Weg ableiten läßt. Es kommen ja
nicht nur Spalten oder Tabellen dazu, sondern es kann auch umgebaut
werden. Wenn z.B. zwei Spalten zusammengefaßt werden, ist das trivial
als SQL-Skript hinzuschreiben:

ALTER TABLE foo MODIFY COLUMN bar VARCHAR();
UPDATE foo SET bar=CONCAT(bar, ' - ', baz);
ALTER TABLE foo DROP COLUMN baz;

Aus dem XML-Schema siehst du nur: "Spalte bar ist jetzt breiter und
Spalte baz gibts nicht mehr". Wo willst du die Information unter-
bringen, daß die Daten von baz nach bar migriert wurden?
Und wie soll das 1. kürzer und 2. einfacher gehen als oben gezeigt?

Beliebig komplizierte Fälle sind denkbar. Mehr noch - wenn die neue
und die alte Version mehr als einen Schritt auseinander liegen, dann
fehlt der Bezug gleich vollkommen, weil z.B. Daten zusammengefaßt
werden, die es erst in einer Zwischenversion überhaupt gab.

> weil man sich nicht mehr Gedanken machen muss
> welche Version der Kunde gerade hat um ggfs. mehrere Dateien einzuspielen.

Das ist doch trivial zu automatisieren:

foreach (sort patches)
if (patch.from == aktuelle_version)
apply(patch)
aktuelle_version = patch.to
end
end

Man kann ja davon ausgehen, daß man keine Patches hat, die eine höhere
als die gewünschte Version erzeugen. Ebenso kann man als gesichert
ansehen, daß man entweder einen lückenlosen Patch-Pfad hat oder daß die
aktuelle Version schlicht zu alt ist.


XL