MySQL Import/Export

Hallo,

ich habe eine Master-Datenbank, in der alle Datensätze angelegt,
editiert und gelöscht werden sollen. Die Änderungen möchte ich
regelmäßig auf externe Slave-Datenbanken übertragen und zwar ohne die
Replikation von MySQL.

Das wichtige ist, daß Relationen zwischen den Tabellen erhalten bleiben,
auch wenn ein Schlüssel bereits im Zielsystem vergeben ist. Das
besondere soll nämlich sein, daß die Nutzer ggf. auch in der
Slave-Datenbank Änderungen vornehmen, oder neue Datensätze anlegen
können und es deutliche Abweichungen zwischen Master und
Slave-Datenbanken geben kann.

Kennt jemand eine PHP-Library oder ein Tool mit dem ich so etwas
realisieren könnte?

Gruß,
Oliver

Re: MySQL Import/Export

Hallo Oliver,
> und zwar ohne die Replikation von MySQL.

Warum?

> Das wichtige ist, daß Relationen zwischen den Tabellen erhalten bleiben,
Relationen? Werden die nicht erst in der Abfrage festgelegt?

> auch wenn ein Schlüssel bereits im Zielsystem vergeben ist. Das besondere
> soll nämlich sein, daß die Nutzer ggf. auch in der Slave-Datenbank
> Änderungen vornehmen, oder neue Datensätze anlegen können und es deutliche
> Abweichungen zwischen Master und Slave-Datenbanken geben kann.
>
Ich kenne nichts fertiges, aber du könntest den automatischen
Primärschlüssel vorne mit nem Index versehen, der die jeweilige Datenbank
kennzeichnet, dann hast du nur jeweils einen Datensatzt mit einem Schlüssel.
Was passiert denn, wenn Datensatz AA auf dem Master und gleichzeitig auf dem
Slave geändert wird? Wer gewinnt?

MfG

Kai

Re: MySQL Import/Export

Kai Koenig wrote:
>> und zwar ohne die Replikation von MySQL.
>
> Warum?

Weil bei der Replikation die Slave-Systeme nur zum Lesen geeignet sind.
Ich möchte eine Art Abo-System erreichen. Das Daten-Grundpaket ziehen
die Slaves regelmäßig vom Master und dann ist es jedem Betreiber selbst
überlassen, ob er Datensätze hinzufügt, ändert, oder löscht.

>> Das wichtige ist, daß Relationen zwischen den Tabellen erhalten
>> bleiben,
> Relationen? Werden die nicht erst in der Abfrage festgelegt?

Ja, man müßte die aber trotzdem formulieren können, sonst könnte es
passieren, daß ein Primärschlüssel aus Tabelle A bereits vorhanden ist,
das System dann einen neuen erzeugt (z.B. per auto-increment) und alle
JOIN-Statements auf diesen Datensatz ins Leere gehen bzw. den falschen
Datensatz erwischen.

>> auch wenn ein Schlüssel bereits im Zielsystem vergeben ist. Das
>> besondere soll nämlich sein, daß die Nutzer ggf. auch in der
>> Slave-Datenbank Änderungen vornehmen, oder neue Datensätze anlegen
>> können und es deutliche Abweichungen zwischen Master und
>> Slave-Datenbanken geben kann.
> Ich kenne nichts fertiges, aber du könntest den automatischen
> Primärschlüssel vorne mit nem Index versehen, der die jeweilige
> Datenbank kennzeichnet, dann hast du nur jeweils einen Datensatzt mit
> einem Schlüssel.

Die Idee hatte ich auch schon, aber der Aufwand wäre sehr groß, weil ich
ne Menge Auto-Increment Primärschlüssel habe.

> Was passiert denn, wenn Datensatz AA auf dem Master
> und gleichzeitig auf dem Slave geändert wird? Wer gewinnt?

Das wäre dann dem Betreiber der Slave-Datenbank überlassen.

Re: MySQL Import/Export

Hi Oliver

Oliver Benning wrote:
> Kai Koenig wrote:
>>> und zwar ohne die Replikation von MySQL.
>> Warum?
> Weil bei der Replikation die Slave-Systeme nur zum Lesen geeignet sind.
> Ich möchte eine Art Abo-System erreichen. Das Daten-Grundpaket ziehen
> die Slaves regelmäßig vom Master und dann ist es jedem Betreiber selbst
> überlassen, ob er Datensätze hinzufügt, ändert, oder löscht.

Sende den Leuten doch einfach dumps. Wenn du willst, kannst du noch
einen automatisierten Upload der Dumps anbieten. Du könntest dann mit
dem Script noch prüfen, ob du mit deinen Einträgen manuell geänderte
angepasste überschreiben würdest und die kundenbasierte erst
rausschreiben. Dann soll der Kunde nochmals entscheiden, welchen Eintrag
er nun neu wünscht. Siehe dazu auch die Softwaredistribution bei bspw.
Debian. Da wird erst gefragt, bevor ein geändertes Config-File von der
neuen Version des Pakets überschrieben wird.

>>> Das wichtige ist, daß Relationen zwischen den Tabellen erhalten
>>> bleiben,
>> Relationen? Werden die nicht erst in der Abfrage festgelegt?
> Ja, man müßte die aber trotzdem formulieren können, sonst könnte es
> passieren, daß ein Primärschlüssel aus Tabelle A bereits vorhanden ist,
> das System dann einen neuen erzeugt (z.B. per auto-increment) und alle
> JOIN-Statements auf diesen Datensatz ins Leere gehen bzw. den falschen
> Datensatz erwischen.

Das erfordert eine Metasprache.

>>> auch wenn ein Schlüssel bereits im Zielsystem vergeben ist. Das
>>> besondere soll nämlich sein, daß die Nutzer ggf. auch in der
>>> Slave-Datenbank Änderungen vornehmen, oder neue Datensätze anlegen
>>> können und es deutliche Abweichungen zwischen Master und
>>> Slave-Datenbanken geben kann.
>> Ich kenne nichts fertiges, aber du könntest den automatischen
>> Primärschlüssel vorne mit nem Index versehen, der die jeweilige
>> Datenbank kennzeichnet, dann hast du nur jeweils einen Datensatzt mit
>> einem Schlüssel.
> Die Idee hatte ich auch schon, aber der Aufwand wäre sehr groß, weil ich
> ne Menge Auto-Increment Primärschlüssel habe.

Es ist sicher einfacher als ne Metasprache zu entwickeln.

>> Was passiert denn, wenn Datensatz AA auf dem Master
>> und gleichzeitig auf dem Slave geändert wird? Wer gewinnt?
> Das wäre dann dem Betreiber der Slave-Datenbank überlassen.

s.o.

HTH, Johannes