"Synchronisations-Theorie"

[Klaus Mock]

Hallo,

Auweia, da muß ich mir doch glatt was neues überlegen. Da kommt aber wieder eine andere Variante ins Spiel, die ich von Philipp Hasenfratz habe und von der mich Sven Rautenberg nur mit Mühe abbringen konnte:
Ich teile den "ID-Raum" untern den Systemen auf, z.B. System 1 hat IDs von 1.000.000.000 bis 1.999.999.999 usw.

Da hatte er sicher Recht, wobei zu bedenken ist, daß zwei Felder mit 32 Bit praktisch einem berechneten Feld mit 64 Bit ist. Allerdings muß man so viel beachten, vro allem die Möglichkeiten der Datenbank, daß auch ich glaube, daß es besser ist, mit zwei Feldern zu arbeiten.

Und autoincrement kannst Du afaik auch gleich vergessen. Das ist zu unflexibel für diese Art von Anwendungen.

Dann müßte ich die IDs nicht nachträglich verändern. Ich sträube mich aber sehr dagagen, ein komplettes Projekt komplett umzubauen, nämlich dann wenn keien eindeutige ID mehr gegeben ist. Wie gesagt, alle Parameter, Links, Formulare, Header-Weiterleitungen, SELECTS, INSERTS, UPDATES... und bestimmt einiges was ich vergessen werde ;-)

Naja besser ist es aber doch, sich beizeiten von einem mangelhaftem Konzept zu lösen, als es mit aller Gewalt in die Zukunft retten zu wollen. Meist kommt nur ein vielfaches an Arbeit raus. Naja, wenn man es bezahlt bekommt, wäre das ja eher ein Argument dafür *ggg*.

Kann man das vielleicht mit Foreign Keys lösen? Ich hatte eh vor erst alle Datensätze zu löschen und zu überschreiben!

Foreign-Keys haben mit den konsistenten Beziehungen der Daten in verschiedenen Tabellen zu tun, niicht mit der ID-Generierung. Die ID's müssen schon vorher festgelegt sein.
Und Löschen und Neuschreiben finde ich für wirklich gefährlich. Was, wenn aus irgendeinem Grunde das Insert nicht mehr funktioniert? Woher sollen dann die Daten rekonstruiert werden. Denke auch an unvorhergesehenes wie Stromausfälle und so weiter. Konsistenz ist für solche Sachen oberstes Gebot.

Naja, eine Lösung gäbe es ja dafür, XNTP. Das wäre sowieso das beste, allerdings mußt Du dann auch sicher sein, daß der immer funktioniert. Ich hatte anfangs schon Problem, wenn der Rechner auf dem die Sync-Engine läuft eine andere Zeit gegenüber dem Datenbanksystem hat.
Das läuft bei mir immer auf jeweils einer Maschine.

XNTP-Clients sollten alber dann auf allen laufen. BTW.: mit Tardis (weiß den Link momentan nicht) habe ich recht gute Erfahrungen, wenn es um XNTP unter NT/2000 geht.

»»» OK, vermutlich hast Du das ganze auf einem etwas höheren Level gemacht, ich verwende rundrum MySQL und das wird auch so bleiben. Da die Anwendung auf allen Systemen dieselbe ist, ist auch dei komplette Datenstruktur gleich, daher reicht das Wissen um die eigene Datenstruktur vollkommen aus! Änderungen müssen auf allen Systemen durchgeführt werden.

Nein ich meinte, daß es nicht nur die Struktur, sondern auch die Daten kennen muß. Wie sonst soll es entscheiden, ob Insert oder Update richtig sind? Für meinen Geschmack zuviel notwendiges Wissen. Außerdem entscheidet dann immer das eine System, was auf dem anderen passieren soll. Da entstehen imho zu viele Verflechtungen.

Aber Du hast Recht, daran soll es nicht liegen, vermutlich läßt sich Deine Version dafür besser komprimieren, und schon ist es egal! Hast Du das eigentlich auch implementiert, eine Komprimierung?

Nein, ich wollte mir das nicht antun und Zeit war auch keine dafür. Nach unseren Tests war der Verbindungsaufbau über das Modem sowieso länger (ca 25 sec) als der üblich Datentransfer (ca.10-20 sec). Der gesamte Abgleich dauert doch deutlich länger, da das Remotesystem relativ wenig Rechenleistung hat. Außerdem ist die DB-Performance dort  bei Modifikationen nicht gerade weltrekordverdächtig.

Hast Du auch eine Verschlüsselung eingesetzt?

Ja, TripleDES für die Daten, aber kein SSL.

Das stimmt schon, ich hatte nur Angst das sowas zu langsam wird, da ich auf einem System an Laufzeiten gebunden bin, wenn dann noch die langen Übertragungszeiten dazu kommen... Wenn ich einmal mein Statements direkt im ersten Schritt noch während des Auslesens der Ursprungs-Datenbank generiere, und über das Kommandozeilen-tool einlese, geht das unheimlich schnell. Bei Deiner Variante brauch ich ja jedesmal erst ein SELECT um zu prüfen ob der Eintrag vorhanden, müßte dann in einer Schleife das Statement generieren und dann noch ein INSERT-Statement.

Es leben die Stored Procedures;-)
Ich muß gestehen, daß stored procedures, Trigger usw.  das Leben für solche Sachen erheblich erleichtern, da Du bereits in der Datenbank vieles abbilden kannst, ohne ständig in irgendeiner Anwendung herumzuwurschteln. mySQL ist da nicht ganz so toll bestückt.

Wie machst Du das denn eigentlich mit dem Parsen? Wie bekommst Du die Datensätze für eine Tabelle in einen Array? Ich meine wo "splittest" Du? OK, danach kannst Du bei [EOR] splitten, und dann jeweils bei :, vermutlich schreibst Du das dann jeweils als key-value Paar in einen Array, nur was machst Du wenn in den Daten mal ein ":" vorkommt? So Probleme habe ich alle nicht!

----------------------------------------
my($tabelle,%daten);
foreach(@inputlines) {
 chomp;
 if(/^[EOR]$/) {
    run_import_record($tabelle,%daten) if $tabelle;
  %daten = ();
  }
 elsif(/^[(.+)]$/) {
  $tabelle = $1;
  }
 else {
  my($name,$wert) = split('\s*:\s*',$_,2);
  $daten{$name}=$wert;
  }
 }
----------------------------------------

(In Perl (ungefähr), in C++ ist's etwas komplexer *g*)

Grüße
  Klaus