Replikation: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) |
|||
Zeile 6: | Zeile 6: | ||
Replikation wird eingesetzt sobald mehrere OrgaMon Mandanten eine gemeinsame Datenbasis verwenden sollen. Dabei sind beide voll schreibberechtigt, der Replikationslauf erfolgt im Rahmen des Tagesabschlusses. Welche Bereiche der Datenbank repliziert werden sollen ist frei einstellbar. | Replikation wird eingesetzt sobald mehrere OrgaMon Mandanten eine gemeinsame Datenbasis verwenden sollen. Dabei sind beide voll schreibberechtigt, der Replikationslauf erfolgt im Rahmen des Tagesabschlusses. Welche Bereiche der Datenbank repliziert werden sollen ist frei einstellbar. | ||
* Die normale/aktuelle/mit dem OrgaMon im Moment verbundene Datenbank ist dabei das Ziel. Die DataBaseName= Datenbank ist die Quelle. | |||
* Alle RIDs der Quelle werden durchgegangen | |||
** Wenn der RID gefunden wird, werden alle Felder im Ziel an den Inhalt der Quelle angepasst | |||
** Wenn der RID nicht gefunden wird, wird im Ziel dieser Datensatz angelegt | |||
== Transition == | == Transition == |
Aktuelle Version vom 6. April 2022, 16:30 Uhr
siehe auch Transition
Replikation
Replikation wird eingesetzt sobald mehrere OrgaMon Mandanten eine gemeinsame Datenbasis verwenden sollen. Dabei sind beide voll schreibberechtigt, der Replikationslauf erfolgt im Rahmen des Tagesabschlusses. Welche Bereiche der Datenbank repliziert werden sollen ist frei einstellbar.
- Die normale/aktuelle/mit dem OrgaMon im Moment verbundene Datenbank ist dabei das Ziel. Die DataBaseName= Datenbank ist die Quelle.
- Alle RIDs der Quelle werden durchgegangen
- Wenn der RID gefunden wird, werden alle Felder im Ziel an den Inhalt der Quelle angepasst
- Wenn der RID nicht gefunden wird, wird im Ziel dieser Datensatz angelegt
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. Auch stellen die RID bei Belegen die Belegnummer dar.
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 zu replizierenden Felder 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 // [optional] Felder, die auf 0 gesetzt werden sollten FelderAuf0=RID // 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