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. Und wenn das so ist kann ich mir ja immer noch Gedanken machen. Ich weiß, das sollte man nicht, aber der Preis den ich jetzt dafür bezahle das ich es mir offen halte das es mal so viele Standorte geben wird, ist dermaßen hoch das er durch die geringe Eintrittswahrscheinlichkeit dieses Falles nicht gerechtfertigt ist - es sei denn Du weißt eine Lösung. Zur Not mache 90 Standorte werden, und das ist nun wirklich unmöglich! Dan muß ich abeer am besten die Stellen direkt auf 10 erhöhen.
Ich dachte erst an ein Trennzeichen, oder Buchstaben, aber dadurch wird SELECT wohl deutlich langsamer, als bei Integer, oder?
Trenne gedanklich die optische Darstellung der ID von der tatsächlichen ID-Speicherung in der Datenbank!
Ja, das hört sich so an als wäre das für die Optik, ist es aber nicht. Es ist für einen Synchronisationsmechanismus, den ich auf jede Tabelle anwenden kann, die einen Timestamp und eine derartige 2-teile ID enthält.
Was haltet Ihr davon, würdet Ihr das evtl anders einteilen?
Wenn du sagst, welche Informationen du hast, welche Bedeutung sie haben, und wie sie verknüpft sind, dann kann man einen besseren Vorschlag machen.
OK, aber das ganze ist kompliziert ;-)
Ich habe hier immer mal wieder Threads gestartet, von wegen Synchronisation 2er Datenbanken, genauer einiger bestimmter Tabellen die in 2(und mehr) Datenbanken vorkommen, und in denen parallel Aktualisierungen vorgenommen werden(ich weiß, da braucht es Regeln...), die aber nur über das Internet verbunden sind, und das auch nicht über eine Standleitung. Die höchste Priorität hat die lokale Verfügbarkeit der Daten. Ich habe 4 lokal voneinander getrennte Standorte mit eigenen LANs, jeweils mit eigenem Apache/MySQl Server. 1 davon läuft unter Linux(Online-Shop beim Provider), die andern(Verkauf, Verwaltung) unter Win2K.
In allen Datenbanken sollen möglichst aktuelle Daten stehen, Änderungen, neue Einträge... sollen in allen Datenbanken mit der Synchronisation vorgenommen werden.
Jetzt habe ich z.B. in allen Datenbanken die Tabelle "Bestellungen".
Im Online-Shop kommt ein neuer Eintrag(insert) in diese Tabelle, wenn eine neue Bestellung darüber eingeht. Zur gleichen Zeit gibt der Verkäufer im Shop ebenfalls eine neue Bestellung in besagte Tabelle ein, aber lokal in seinem LAN. Wenn jetzt dazwischen keine Synchronisation der beiden Datenbanken stattgefunden hat, haben die ja dieselbe ID, das ist das Kernproblem.
Damit das nicht passiert, dagegen gibt es im Prinzip nur 2 Wege:
1. eine Ständige Verbindung, oder eine MasterDB die nur IDs verteilen darf, zu der erst Kontakt aufgenommen werden muß, aber da 2 LANs über T-DSL und eines über ISDN anhebunden sind, also per Dailup, ist das zu unsicher, denn wenn dei Telekom mal wieder Mist baut funktioniert das ganze System nicht mehr und der Betrieb steht still!
2. 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!
Und da dieser Punkt noch nicht so ganz optimal ist, habe ich den Thread eröffnet, vielleicht hat hier jemand von Euch, der mehr Erfahrung mit Datenbanken hat eine Idee, wie ich das löse.
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.
Ich hoffe ich habe das verständlich beschrieben, aber ich habe mich soviel damit beschäftigt und so viel probiert, das ich evtl. nicht alles ganz einleuchtend erklärt habe. Würde mich freuen wenn Du eine Idee hast!
Viele Grüße
Andreas