Replikation: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Root (Diskussion | Beiträge) |
||
Zeile 10: | Zeile 10: | ||
== Transition == | == Transition == | ||
Ein Datenbank-Merge unter Berücksichtigung von sich überschneidenden RIDs. | Ein Datenbank-Merge unter Berücksichtigung von sich überschneidenden RIDs. Das Ziel der Transition ist nicht der Gegenseitige Abgleich von zwei OrgaMon-Datenbanken, sondern der Übergang von Daten aus einer Quell-datenbank in eine Ziel- Datenbank. Da die Referenz-Identitäten deckungsgleich sein könnten ist die Datenübernahme nicht 1:1 möglich. Im Rahmen des Übergangs von Daten werden alle RIDs aus der Quelldatenbank so "verfälscht" dass das Bild in der Zieldatenbank wiederum passt.<br> | ||
Liegt z.B. der RID "1" in Quelle und Ziel vor, und soll aber RID 1 der Quelle als neuer Datensatz in das Ziel übernommen werden, so wird im Rahmen der Transition automatisch ein neuer RID für den Datensatz ermittelt z.B. "2". Beim Übergang von abhängigen Tabellen werden auch alle Referenzen auf "1" auf den neuen RID "2" umgesetzt, aufgrund der durchgängigen Namenskonventionen im OrgaMon erfolgt dieser Vorgang automatisch.<br> | |||
Die theoretische Grundlage dieser Vorgehensweise ist die, dass innerhalb einer OrgaMon-Datenbank der konkrete Wert eines RIDs unerheblich ist, würde man also einen RID selbst umstellen und dabei alle Referenzen auch auf diesen neuen Wert umstellen, wäre die Datenbank inhaltlich zur unmodifizierten Datenbank identisch.<br> | |||
In ausnahme-Fällen ist eine Sortierreihenfolge abhängig vom RID. | |||
=== Transitions-Tabellen === | |||
damit die Transition wiederaufsetzbar ist (z.B. nach einem Datenbank-Fehler oder nach einem Benutzer-Abbruch) werden im Rahmen des Abgleiches .csv - Tabellen geschrieben in der "Alter RID" neben "Neuem RID" aufgezeichnet wird. | |||
=== Abhängigkeitsbaum === | |||
Ich gehe davon aus, dass man die Generations-Zähler hierarchisch anordnen kann, mit der Semantik dass Änderungen an einem Knoten eine Änderung an den Blättern implizieren aber nicht umgekehrt. | |||
=== Generations-Zähler === | |||
=== Statements === | |||
Aufgabe eines Statement klassifizierenden Algorithmus wäre es, zu bestimmen von welchen Generations-Zählern ein Q-Statement abhängig ist. Es kann sein, dass die Kette durch Meta-Datenänderungen kürzer oder länger wird. | |||
* Ist das resultierende Element (noch) gar nicht im Cache vertreten ist das Ergebnis "Fail" | |||
Ein Cache-Element dürfte wiederverwendet werden sobald die Kette des Cache-Elements gleich ist mit der Kette | |||
== Parameter == | |||
* Name des Replikations-Schrittes | * Name des Replikations-Schrittes |
Version vom 25. Januar 2019, 17:13 Uhr
siehe auch Transition
Replikation
Replikation wird eingesetzt sobald mehrere OrgaMon Mandanten eine gemeinsame Datenbasis verwenden sollen. Dabei sind beide voll Schreibberechtigt, der Abgleich erfolgt im Rahmen des Tagesabschlusses. Welche Bereiche der Datenbank replizeirt werden sollen ist frei Einstellbar.
Transition
Ein Datenbank-Merge unter Berücksichtigung von sich überschneidenden RIDs. Das Ziel der Transition ist nicht der Gegenseitige Abgleich von zwei OrgaMon-Datenbanken, sondern der Übergang von Daten aus einer Quell-datenbank in eine Ziel- Datenbank. Da die Referenz-Identitäten deckungsgleich sein könnten ist die Datenübernahme nicht 1:1 möglich. Im Rahmen des Übergangs von Daten werden alle RIDs aus der Quelldatenbank so "verfälscht" dass das Bild in der Zieldatenbank wiederum passt.
Liegt z.B. der RID "1" in Quelle und Ziel vor, und soll aber RID 1 der Quelle als neuer Datensatz in das Ziel übernommen werden, so wird im Rahmen der Transition automatisch ein neuer RID für den Datensatz ermittelt z.B. "2". Beim Übergang von abhängigen Tabellen werden auch alle Referenzen auf "1" auf den neuen RID "2" umgesetzt, aufgrund der durchgängigen Namenskonventionen im OrgaMon erfolgt dieser Vorgang automatisch.
Die theoretische Grundlage dieser Vorgehensweise ist die, dass innerhalb einer OrgaMon-Datenbank der konkrete Wert eines RIDs unerheblich ist, würde man also einen RID selbst umstellen und dabei alle Referenzen auch auf diesen neuen Wert umstellen, wäre die Datenbank inhaltlich zur unmodifizierten Datenbank identisch.
In ausnahme-Fällen ist eine Sortierreihenfolge abhängig vom RID.
Transitions-Tabellen
damit die Transition wiederaufsetzbar ist (z.B. nach einem Datenbank-Fehler oder nach einem Benutzer-Abbruch) werden im Rahmen des Abgleiches .csv - Tabellen geschrieben in der "Alter RID" neben "Neuem RID" aufgezeichnet wird.
Abhängigkeitsbaum
Ich gehe davon aus, dass man die Generations-Zähler hierarchisch anordnen kann, mit der Semantik dass Änderungen an einem Knoten eine Änderung an den Blättern implizieren aber nicht umgekehrt.
Generations-Zähler
Statements
Aufgabe eines Statement klassifizierenden Algorithmus wäre es, zu bestimmen von welchen Generations-Zählern ein Q-Statement abhängig ist. Es kann sein, dass die Kette durch Meta-Datenänderungen kürzer oder länger wird.
- Ist das resultierende Element (noch) gar nicht im Cache vertreten ist das Ergebnis "Fail"
Ein Cache-Element dürfte wiederverwendet werden sobald die Kette des Cache-Elements gleich ist mit der Kette
Parameter
- Name des Replikations-Schrittes
PERSON
- Parameter des Replikationsvorganges
// Angabe über das Replikations-Verfahren Mode=Transition|Replication // Angabe der Quelldatenbank, aus der die // Replikation erfolgen soll DataBaseName=192.168.100.181:/srv/fdb/hebu.fdb // Quelltabelle Tabelle=PERSON // Generator (optional) Generator= // Umfang der Überprüfung Umfang=RID=163 // Indizes, die während der Replikation // deaktiviert werden sollen Indizes=PERSON_NUMMER_A,PERSON_NUMMER_D // Felder, die im Ziel leer bleiben sollen OhneDieFelder=RABATT_CODE,LETZTEAENDERUNG // Bestimmen der Felder, die nur im falle des insert hinzugenommen werden sollen ("RID" ist Standard) NurBeiInsert=
- Auflistung aller Möglichkeiten
DataBaseName=
Tabelle=
Umfang=
Indizes=
OhneDieFelder=
Referenzen auf sich selbst
Das Problem besteht darin, dass im Rahmen der Replikation Referenz-Zeiger auf Datensätze angelegt werden sollten die noch nicht existieren. Dadurch wird eine "FOREIGN KEY EXCEPTION" ausgelöst. Die Lösung ist 2 stufig zu Replizieren, also erst die Datensätze selbst ohne Zeiger, danach alle Felder!
- Datensätze zunächst zum Leben erwecken, OHNE Zeiger
DataBaseName=192.168.100.181:/srv/fdb/old.fdb Tabelle=MUSIKER OhneDieFelder=MUSIKER_R,EVL_R
- Jetzt nochmal, diesmal alles!
DataBaseName=192.168.100.181:/srv/fdb/old.fdb Tabelle=MUSIKER