nicht angemeldet
Hallo!
Du brauchst ja nur ca. 8bit für die DatenbankID und den Rest für die ID der Records. Ja, mit zwei Feldern zu arbeiten wäre in der Tat viel besser, aber: dann hast du ein Feld DatenbankID und eine ID mit autoinc. Jeder Datensatz ist bezogen auf das System unique, aber dann müsste Andreas die DatenbankID immer noch in die SQL Abfragen einfügen => ARBEIT...
Wie gesagt, es sind nicht nur die Abfragen, was mir noch eingefallen ist - das Problem besteht ja lediglich bei Verknüpfungen. Und wenn ich die Variante mit den 2 Ids verwende, dann müßten ja auch alle Verknüpfungen über 2 IDs gehen, Also müßte ivch auch noch die ganzen betroffenen Tabellen umstellen, bekäme große Probleme mit aktuellen Daten... das ist doch alles Mist. Wenn man das von vornherein dafür entwickelt, OK, ist vermutlich das sauberste, aber im nachhinein gibt es so viele Probleme!
Und autoincrement kannst Du afaik auch gleich vergessen. Das ist zu unflexibel für diese Art von Anwendungen.
Ja, den müsste man selber implementieren. Klar, wenn man den ID Raum aufteilt, kommt man nicht darum herum; es sei denn man könnte den startindex im Tableheader festlegen.
Kann man ja einfach durch einen Dummy-Datensatz mit der ersten ID!
Nun, bei der Synchronisation treten ja leider noch mehr Probleme auf: Was, wenn der Datenbestand auf einer DB ändert, noch während der Synchronisation? - In den meisten Fällen kann man das mit den Flags und Timestamps ja "unterbinden", aber 100% ist die Lösung auch nicht. Man müsste theoretisch während der Synchronisation die Table locken,
genau das habe ich vor!
Ich weiß es einfach nicht. Für die nachträgliche Implementierung sehe ich eigentlich nur eine Chance für 2 Varianten:
1. begrenzter ID-Raum
2. Vergabe und ggfs. Überschreibung der ID durch den Master, und das Feld HerkunftsID, wo immer die ID des Systems der letzten Änderung gespeichert wird. Wenn der Master dann einen Datensatz hat, der nach der letzten Synchronisation geändert wurde, kann man anhand der HerkunftsID sehen ob die Daten auf dem Client aktualisiert werdn müssen. Leider kann man so doch nicht wie ich zunächst annahm Rückschlüsse darauf ziehen ob ein Update oder in Insert von nöten ist. Also muß ich das wohl oder überl doch client-seitig ermittlen. Dann bekomm eich aber Probleme mit den IDs, da sich hier ClientIDs und MasterIDs in einer Spalte mischen. Aber dafür bräuchte ich eine weitere Spalte mit einem Flag welches geändert wird sobald eine Synchronisation erfolgt ist, so kann ich die gültigen MasterIDs herausiltern.
Problem Nr.2 wäre dann noch die Verknüpfungen wieder hinzubiegen. Wie würde man das am besten machen? Das Problem ist, dass das so nicht mehr unabhängig von der Datenstruktur gesehen werden kann, also muß ich das ganz speziell programmieren und bei Änderungen anpassen.
Dann muß ich die alte ID wieder mit zurückschicken und bei jedem Insert die entsprechende Verknüpfung anpassen... sehr kompliziert, vor allem wenn man viele Tabellen hat und viele Verknüpfungen.
Eine andere Lösung wäre es vielleicht, noch ein Feld einzufügen, nämlich eine autoinc-ID des Clients. Aber ich glaube auch das bringt mich nicht wirklich weit nach vorne, denn sobald ich Verknüpfungen habe bekomme ich dasselbe Problem, entweder ich ändere die komplette Struktur der Verknüpfungen auf 2 IDs oder ich versuche es doch mit dem ID-Raum, das wäre das mit Abstand einfachste!
Viele Grüße
Andreas