nicht angemeldet
Hi Sven!
die Erste ID könnte ruhig eine Zahl zwischen 1-9 sein, die steht für den Standort, die ander ID ist die autoincrement ID des Datensatzes. Die IDs sollten aber überall gleich sein.
Die Gefahr besteht, dass sich der Standort ändern kann. Oder dass sich plötzlich mehr als 10 Standorte ergeben. In beiden Fällen würdest du die bislang eindeutige ID verändern bzw. an Grenzen gelangen, die vollkommen unnötig sind.
Das ist dann mein Problem. Wenn es > 9 Standorte geben sollte mach ich ein Faß auf und besauf mich, zumindest sehe ich zur Zeit (leider) nicht in Ansätzen das die Zahl erreicht wird.
Da du nicht wirklich "Standorte" hast, sondern im Prinzip nur "Datenbankenstandorte", könnte es ganz schnell passieren, dass du mehr als 9 "Standorte" hast. Jetzt sind es schon 4. Dann gib noch 5 Mitarbeitern einen Laptop für die mobile Datenerfassung in die Hand - schon hast du 9 Standorte. Wenn dann noch ein Backup-System für den Shop dazukommt (zweiter Server, kriegt bis zum Ernstfalleinsatz immer nur Daten geliefert - Nummer 10), und noch zwei Filialen (Nummer 11 und 12)... Naja, es ist jedenfalls Blödsinn, irgendeine Begrenzung einzubauen, die sich irgendwann durch irgendwelche Umstände als außerst störend erweisen könnten - sieh' dir einfach nur das Jahr2000-Problem an!
Siehe dazu auch http://www.tuxedo.org/~esr/jargon/html/entry/Zero-One-Infinity-Rule.html.
- Kombination aus eigenen IDs und Standort-IDs, dadurch wird es wieder eindeutig. Hierfür gibt es meines Wissens Primärschlüssel über 2 Spalten, da nur über diese beiden Ids eine Eindeutligkeit des Datensatzes garantiert ist.
Aber das Problem, wenn man zwei Spalten(Standort-ID, Datensatz-ID) verwendet, dann ändern sich auch alle Zugriffe auf die Datenbank, man kann nicht merh abfragen "WHERE ID =123", man braucht dann "WHERE ID1=12 AND ID2=3232"
Und das will ich unbedingt vermeiden, indem ich nur eine einzige ID verwende aber eine eigene insert-Funktion baue, die zuerst die Tabelle lockt, danach die höchste ID mit der eigenen StandortID am Anfang ermittelt, diese um 1 erhöht, und in den Query-String schreibt!
Warum willst du das Unvermeidliche vermeiden? Du brauchst eine ID zur Identifikation des Datensatzes, und eine ID zur Identifikation der Erfassungsdatenbank - die Kombination beider ist eine systemweit eindeutige ID. Ein SELECT mit zwei Bedingungen ist zwar etwas langsamer als ein SELECT mit nur einer Bedingung - aber immer noch wesentlich schneller, als ein SELECT mit concat() (um die zwei IDs zu verbinden, bevor eine Bedingung wirksam wird).
Allerdings ist das nicht die einzige Möglichkeit...
Die eigentliche Synchronisation führe ich dann mit curl durch, hiermit übertrage ich die Daten über SSL zum anderen Server, wo ein Script auf die Daten wartet, die neuen Daten schreibt und die eigenen Änderungen ermittelt und zurückschickt. Erst war noch eine GPG-FTP Kombination im Gespräch, nachdem SCP ausgeschieden war, aber die curl-Variante ist wohl die einfachste! Die zu synchronisierenden Daten werden per SQL aus der jeweils lokalen Datenbank ausgelsen.
Erkläre eine Datenbank, die dauerhaft erreichbar ist, zur Master-Datenbank. Zu dieser Datenbank werden alle extern eingegebenen Daten hochgeladen, und sie hat im Zweifel die einzig gültigen Daten.
Mir fallen zwei Methoden ein, die beide dasselbe Prinzip verfolgen.
1.) Du hast zwei ID-Felder. Eine ID ist die endgültige ID. Diese ID wird vergeben, wenn der Datensatz in die Master-DB eingetragen. Bis es soweit ist, werden in den dezentralen Datenbanken temporäre IDs vergeben.
2.) Um das Gehampel mit zwei ID-Feldern zu vermeiden, könntest du auch ein ID-Feld und ein Herkunftsfeld definieren. Das Herkunftsfeld definiert, welche dezentrale Datenbank zur Eingabe verwendet wurde. Wenn der Datensatz zur zentralen Datenbank hochgeladen wird, wird das Herkunftsfeld geändert und eine neue ID vergeben. Die Änderung wird dann zurückgesendet, bzw. generell komplett verteilt.
Mit diesem System kannst du anhand der Herkunfts-ID sehen, ob der Datensatz schon zentral gespeichert wurde.
Ich bin sicher, dass tausend Gründe, die du noch nicht genannt hast, in irgendeiner Weise gegen diese Vorgehensweise sprechen - dann bleibt eben nur die Möglichkeit, ID und Herkunfts-DB einmal beim ersten Erfassen des Datensatzes zu vergeben und immer beizubehalten. Ich würde davon abraten, diese zwei Informationen zu vermischen.
- Sven Rautenberg