|
Datenbank: MariaDB • Version: 10.3.7 • Zugriff über: MyDac
Konzeptionelle Frage - Datenabgleich
Hi!
Ich wollte mal hiermit fragen, was ihr für Ideen hättet: Es sollen Daten zwischen verschiedenen Standorten abgeglichen werden. Beispielsweise soll ein neu angelegter Kunde aus einem Standort auch an einen anderen übertragen werden. Wir haben uns hier in der Firma natürlich auch schon was überlegt, aber ich wollte mal in die Runde fragen, auf was für Ideen ihr kommen würdet? Was uns (parallel auch) noch eingefallen ist, war das Stichwort "Replication-Server", vielleicht weiß jemand ob das in dem Zusammenhang relevant ist und falls ja wo man idiotensicher ( ;-) ) erfährt wie das funktioniert. Es soll möglich sein, dass an beiden Standorten "gleichzeitig" Kunden (und natürlich auch andere Daten, aber das wäre dann ja übertragbar) angelegt werden können und diese dann untereinander abgeglichen werden. Es gibt ja sicher auch hier State-Of-The-Art-Lösungen, aber welche wäre das? Als Datenbank dient MariaDB (also so ähnlich wie MySQL), zum "drauf schauen" nehmen wir "HeidiSQL" (falls das überhaubt relevant ist) und zum Entwickeln Delphi 10.2 mit MyDac auf Windows 10 x64. Ich hoffe ich habe alle interessanten Infos genannt und freue mich auf Hinweise, Links, Ideen, Vorschläge und all' das woran ich gerade nicht denke! Vielen Dank schonmal für die Mühe und Zeit! Liebe Grüße und euch allen schonmal einen wunderschönen Tag Incocnito |
AW: Konzeptionelle Frage - Datenabgleich
 Replication ist da sicher das richtige Stichwort und die Doku von MariaDB gibt ja auch eine grobe Übersicht dazu. Erfahrung habe ich persönlich nur mit MS SQL Replikation, kann also leider nicht viel bei MariDB weiterhelfen. |
AW: Konzeptionelle Frage - Datenabgleich
Replikation ist eine Einbahnstraße, das hilft dir hier nicht unbedingt. Du brauchst eher Synchronisation.
Hier gibt es einen Ansatz dazu: https://www.hagenfragen.de/linux-tip...?cn-reloaded=1Diese Fragen solltest du aber beantworten können, bevor du an eine Umsetzung gehst: - Wir erkennst du, ob ein Datensatz (Kunde, Artikel, etc), der in DB A neu ist, bereits in einer anderen DB vorhanden ist. - Was passiert bei so einer Kollision? Wird auf Feldebene gemerged Oder der ganze Satz übernommen? - Können Kollisionen überhaupt auftreten? - Wie oft werden Kollisionen auftreten? - Wie lange können Synchronisationen im Status "pending" bleiben? Je kürzer desto besser, weil sonst die Wahrscheinlichkeit, dass der Satz in anderen DBs auch angelegt wird, steigt. - Gibt es zyklische Abhängigkeiten? Beispiel: In DB A kann Kunde X gelöscht werden, weil er noch keine Buchungen hat. In DB B darf er aber nicht gelöscht werden, weil es schon Buchungen gibt. Stichwort: verteilte Transaktionen. Grobkonzept: Ich würde eine Tabelle machen: - Database - Kennzeichen Insert/Update/Delete - Tabelle - Feld - Inhalt - Timestamp - Kennzeichen ob schon gesynct - Applied Jede Änderung wird lokal in der Tabelle mitgeschrieben. Wenn du Syncst, holst du dir aus allen anderen DBs diese Inhalte + duplizierst sie in deine Tabelle (dort Status setzen!). Dann arbeitest du dich in chronologischer Reihenfolge durch (Applied:=Y). Wie oft du syncst + ob die das syncen bei einem anderen anstoßen kannst, sind Details. Wahrscheinlich musst du Löschen gesondert behandeln, siehe oben. |
AW: Konzeptionelle Frage - Datenabgleich
Hallo,
wie sind denn deine Standorte untereinander verbunden? Welche Latenzen sind da vorhanden? Wir haben bei uns seit Jahren einen global erreichbaren Master-Mysql-Server auf dem alle Schreibvorgänge stattfinden und je Ort einen Slave-Server der für die Lese-Zugriffe zuständig ist. Fällt der Master-Server aus, kann allerdings niemand mehr Änderungen tätigen. Langfristig planen wir auf eine Master-Master Replikation umzusteigen. Bisher haben wir damit leider keine Erfahrung. |
AW: Konzeptionelle Frage - Datenabgleich
Hallo,
Replication=Synchronisation, wenn ich in beide Richtungen replizieren. Wichtig sind verschiedene Nummernkreise für die DB-Ids. Jeder Standort einen anderen. Bsp: Kunden-Id Standort1: 1-1.000.000 Standort2: 1.000.001-2.000.000 Dann finden schon mal keine unschönen Kollisionen bei den Primary Keys auf DB-Ebene statt. Logische Kollisionen (doppelte Kundennummer) müssen intelligent gelöst werden. Die anderen Vorschläge (Änderungstabelle) sind genau richtig. So hatte ich das damals mal unter Firebird bei einem Kunden implementiert. Das Füllen der Tabelle erfolgt sinnvollerweise durch die DB selbst (Trigger). Hier noch ein Link zum IBReplicator-Handbuch für grundlegende Sachen http://www.ibphoenix.com/downloads/i...ator_2_5_2.pdf |
AW: Konzeptionelle Frage - Datenabgleich
Ich hatte auch einmal das "Vergnügen" eine LotusNotes DB vertretungsweise zu betreuen. Bei der Replizierung traten immer wieder Fehler auf, die nur durch Handarbeit zu beheben waren. Das hierfür intime Kenntnisse der Inhalte nötig waren, war den Benutzern nicht klar, dementsprechend unwirsch reagierten sie auf Anfragen nach den "richtigen" Daten. Seither bevorzuge ich zentrales DB-Schreiben.
Gruß K-H |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Das ist eine interessante Frage welche "Primary keys" man am Besten nutzen sollte, diese Frage kommt bei mir auch schonmal ab und an auf. Normalerweise nehme ich gerne Integer, aber zum Synchronisieren mit mehreren verteilten Systemen wäre TGuid eigentlich besser geeignet, oder eine Art von Timestamp mit ID ? Könnte man Alles auch als String abbilden, aber das wäre wohl schlecht für die Performance. Gibt es noch bessere Alternativen, z.B. zusammengesetzte Columns, etc. ? Ich habe bisher den echten GUID noch nicht dafür eingesetzt, könnte es vielleicht irgendwelche Probleme damit geben (z.B. doppelte ID's) ? Rollo |
AW: Konzeptionelle Frage - Datenabgleich
BigInt mit unterschiedlichen Initialwerten der Sequenzen sollte ausreichend sein.
|
AW: Konzeptionelle Frage - Datenabgleich
|
AW: Konzeptionelle Frage - Datenabgleich
Hallo,
ich hatte Integer benutzt. |
AW: Konzeptionelle Frage - Datenabgleich
Lustig wird das wenn ein Nummernkreis doch mal überläuft :stupid:
|
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Gruß K-H |
AW: Konzeptionelle Frage - Datenabgleich
Sequenz/GUID/Überlauf:
Wir haben in einem Offline System für Bestellungen mal mit GUID gearbeitet. Hat problemlos funktioniert, allerdings sind in dem Kleinprojekt keine nennenswerten Mengen zustande gekommen. Dubletten: Diese Problematik ist ätzend, und am Ende ist der Physiker noch Sauer und eigentlich Chemiker! ;) Aber m.E. ist das Problem nicht unbedingt an verteilte Systeme bzw. technische ID gekoppelt. Also vlt. beide Probleme nicht in einer gemeinsamen Lösung vermischen. |
AW: Konzeptionelle Frage - Datenabgleich
Wir haben ein selbstgebautes Tool im Einsatz das mehrere ADS Datenbanken abgleichen soll. Es wird für jede Änderung ein Job angelegt. Der Job ist erst abgearbeitet wenn die Gegenstellen bestätigt dass die Änderung korrekt übertragen ist.
Das Ding macht immer wieder Probleme. Es ist teilweise Hell on Earth. Nummern Kreise laufen über. Oder gegenstelle hat ein neues Modem oder neu Software oder neue Hardware bekommen. Oder der Virenscanner meint alles zu blocken. Wir überwachen die Anzahl der Jobs um „Verstopfungen“ rechtzeitig zu erkennen. Am schlimmsten ist das die Gegenstelle nicht permanent erreichbar ist. Über eine Cloud Lösung wurde schon nachgedacht. Es sind aber über 30 Verbindungen die Synchronisiert werden. Naja kompliziertes Thema.. |
AW: Konzeptionelle Frage - Datenabgleich
So mancher nimmt hier als ID einen TIMESTAMP (mit Millisekunden) oder sowas wie eine GUID
und geht erstmal davon aus, dass es womöglich fast nie vorkommt, dass auf beiden Seiten genau zur selben Zeit ein Datensatz hinzukommt. (was natürlich aber dennoch einmal passieren könnte) Da es aber dennoch ab und an mal vorgekommen ist, habe ich bei uns einige der Synchronisationen umgestellt. Also intern wird mit einer Integer-ID gearbeitet, welche aber nur innerhalb einer DB genutzt wird, aber bei der Synchronisierung werden eine/mehrere andere eindeutige Spalten genutzt und diese ID wird bei der Datenübertragung ignoriert. Eventuell wird auch diese ID noch "umgerechnet", falls weitere Tabellen ebenfalls synchronisiert werden und sich über diese ID referenzieren. Also in allen Tabellen/Daten diese ID von lokaler DB durch ID der anderen DB ersetzt, bei der Datenübertragung (referenziert über die Synchronisationsfelder). |
AW: Konzeptionelle Frage - Datenabgleich
Mache folgendes:
Alle Tabellen, die gesendet oder empfangen werden, bekommen 3 zusätzliche Felder: Lastchange Timstamp wird per Trigger gesetzt Lastupdate Timestamp wird gesetzt wenn Datensatz exportiert wird, dann NOW + ein paar Sekunden AGUID wird erzeugt wenn Datensatz erstmalig gesendet wird. Der Empfänger prüft dann ob AGUID schon existiert, wenn ja dann Update sonst Insert. Natürlich muss man noch auf Nummernkreise und ev. AutoInc-Felder achten. Löschbefehle komme in Del-Tabellen, die auch automatisch angelegt werden. Kommunikation geht entweder über eine einfache Soap-Schnittstelle oder über Dateien, die z.B. in einer Dropbox o. ä. geschrieben werden. Bei Dateien liest der Empfänger die Daten ein und löscht sie dann. Die Daten sind im JSON-Format. Ich benutze eine sehr nützliche Funktion aus dem Delphi-MVC Framework, die sehr einfach den Export und Import von JSON-Arrays in Datasets ermöglicht. Gibt natürlich noch einige Details, aber kann das jetzt nicht alles beschreiben |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Wir haben sowieso an fast allen Tabellen ein paar automatisch angelegte Felder für InsertTime, UpdateTime und wer das war. Aber zusätzlich gibt es an synchronisierten Tabellen auch noch dieses "Modified"-Feld für die Synchro, wobei dieses Feld nicht nur angibt wer neuer ist, sondern auch für den Vergleich benutzt wird. > Tja, nutzt man dieses Datumsfeld nun für einen billigen "hat sich was geändert"-Vergleich, oder vergleicht man da wirklich alle Spalteninhalte? (ausgenommen denen, welche von der Synchro ausgeschlossen sind) |
AW: Konzeptionelle Frage - Datenabgleich
In einer kleineren Testumgebung habe ich das vor relativ langer Zeit mal so gelöst:
Keine Replication auf DB-Ebene. Je eine DB an jedem Standort, und diese einmal vollständig übertragen. Jede Tabelle hat ein Lock-Feld. Wird nun ein Datensatz an Standort A zum Bearbeiten geöffnet, so wird sowohl der Datensatz sowohl in DB A als auch in DB B mittels dem Lock-Feld gesperrt. Heißt er kann nur noch zum Lesen geöffnet werden. Wird er nun in DB A gespeichert, dann wird dort das Lock direkt aufgehoben. Anschließen wird er dann in DB B gespeichert und erst danach das Lock auch dort aufgehoben. Das ganze muss natürlich im Client passieren, oder man muss den DB-Zugriff über eine Server-Application regeln, die dann das Sperren und Entsperren passig übernimmt. In die andere Richtung würde das genauso funktionieren. Und auch mit mehr als 2 Standorten. Hat, wenn ich mich recht erinnere damals ohne Probleme funktioniert. War aber nur ein Test. Wir haben damals zwar einige an Traffic simuliert, aber ob es einem Echt-Betrieb standgehalten hätte kann ich nicht mit Sicherheit sagen. Sollte aber. Das natürlich 2 User auf beiden Seiten zeitgleich den gleichen Kunden anlegen kann dieses Verfahren natürlich nicht verhindern. Und das Handling ist natürlich auch von der zur Verfügung stehenden Bandbreite abhängig. Ob sich sowas auch auf DB-Ebene realisieren ließe, kann ich nicht sagen. Dazu fehlt mir das Wissen. |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Zitat:
Du hast den Datenbankkunden, der Daten erfasst und diese natürlich sofort verfügbar haben will. (ich weiß, es gibt genügend Systeme, da sind neue/geänderte Daten erst am nächsten Arbeitstag verfügbar und an zwei Tagen im Jahr funktioniert es nicht richtig und schon ist das System S......) Auf der anderen Seite der Admin/Programmierer, der eine funktionierende Formallösung sucht. Diese Formallösung zu finden, dafür wurden bisher schon genügend Ansätze skizziert. Aber sind damit auch die Ansprüche des Kunden abzudecken? So lange alle Standorte weitgehend unterschiedliche Daten erfassen, - lesen ist ja kein Problem - bist Du mit einer rein formalen Lösung ganz gut bedient. Wenn es aber Datenüberschneidungen gibt, muß neben der formalen Programmlösung auch eine organisatorische Lösung her. Wie auch immer diese aussehen mag. Nicht daß wir uns falsch verstehen, DDP-Systeme sind für 80%-Lösungen bei 50% der Kosten gut zu gebrauchen. Wer aber 100% will muß auch 100% zahlen. (falls sich jemand fragt woher ich meine Prozente habe, meine ersten Schritte hab ich auf einer IB8100 gemacht) Gruß K-H |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Ich wollte nur zum Ausdruck bringen, das es 2 verschiedene Probleme sind, die nicht unbedingt durch den gleichen, superschlauen Algorithmus zu lösen sind. |
AW: Konzeptionelle Frage - Datenabgleich
Ohne jetzt den ganzen Strang zu lesen, meine Lösung für ein Mobiles Bestellwesen für Aussendienstler und ein autonomes POS ist folgendes :
Tabellen wie Produkte und Kunden kriegen ein Feld LU (LastUpdate, Datetime) und auf der Abgleichseite (also der mobilen app oder dem pos speicher ich mir für jede Tabelle (sind ja eh nicht viele) einfach nur wann ich dasletzte Mal nachgefragt habe. Beim Sync sage ich dann nur Tabelle: Produkte LastUpdate: 13.02.2018 14:15:23.758 (also mit millisekunden eben) und zurück kommen allen Zeilen aus der Tabelle, die einen LU timestamp haben, der neuer ist. Das Ganze mache ich mit RealThinClient (RealThinClient.com), da kann ich ganze DataSets komprimiert übermitteln. Auf der Clientseite geht das dann mit einem Batchmove (Append/Update) in meine lokale Tabelle. Das nutze ich so seit 2 Jahren und alles ohne Probleme. Hoffe, dass es hilft. |
AW: Konzeptionelle Frage - Datenabgleich
@MyRealName:
Das ist aber eine Einbahn, oder? Die Updates gehen immer raus zum Pos + nie zurück? @HobbyCoder: Das führt bei mehreren Usern + etwas mehr Traffic zu Deadlocks. Never leave the commit to the user. Da öffnet einer den Satz zum Bearbeiten + geht Mittagessen, dann steht bald alles. Ob es genügt, sich nur den Zeitstempel und die letzte Änderung zu merken oder ob man auch alle Zwischenversionen braucht, ist eine Frage der Anforderungen. Wenn ich zB in meiner App ein Änderungsprotokoll mitführen möchte, dann ist es wichtig, dass ich von den anderen Standorten nicht nur die letzte Änderung bekomme, sondern chronologisch alle Änderungen davor auch. Oder Kennzahlen etc. |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Wenn ein User den Datensatz bearbeitet, er nicht gelockt wird und er dann zu Mittag geht, kann in der Zeit ja ein anderer diesen Datensatz ebenfalls bearbeiten. Kommt der erste Mitarbeiter vom Mittag zurück und speichert, überschreibt er die Daten vom zweiten Mtarbeiter. Dann lieber eine Benachrichtigung in der Art: „Datensatz bei xyz in Bearbeitung“. Habe ich so in Nähe zu allen Programmen von mir, und Userbeschwerden gab‘s noch nie. |
AW: Konzeptionelle Frage - Datenabgleich
Optimistic locking vs pessimistic locking. Der TE wollte ja konzeptionellen Input.
Wenn´s für dich funktioniert ist es eh super. Ich sag nur: Je höher die Concurrency und/oder je höher die Benutzerzahl und/oder je höher die Komplexität der DB-Struktur ist, desto weniger funktioniert das Locken im Voraus. Zitat:
|
AW: Konzeptionelle Frage - Datenabgleich
Moin,
mit der Erfahrung einer von uns implementierten Async Multimaster Replikation mit ca. 160 Server in Deutschland in diversen Städten verteilt, auf denen innerhalb von 24 Stunden ca 1,5 bis 2 Millionen neue oder geänderte Datensätze entstehen, geb ich einfach auch mal meinen Senf dazu (auch wenn das alles mit Firebird und nicht mit mysql implementiert wurde). -Wir benutzen 64 Bit Integer als PK und für jeden FK und in jeder Tabelle heisst das PK Feld immer ID (vereinfacht nachher sehr viel) -Integer ist schon eng, bei 24/7 Betrieb mit einer Transaktion pro Sekunde und wie wir alle wissen 86400 and den meisten Tagen hält ein 32 bit Integer zwar ca 130 Jahre bis zum Überlauf, aber bei 10 pro Sekunde sind das nur noch 13 Jahre. 100 pro Sekunde dann nicht mal 1,5 Jahre. Beim 64 Bit kannst du 4 Mrd Werte pro Sekunde verbraten und das hält immer noch 130 Jahre. Geiz ist nicht wirklich geil .... -Alle Tabellen werden aus einer Quelle (also nur ein Firebird Generator) gefüllt -An jedem Standort wird bei Auslieferung eine Boxnummer festgelegt und die mit 10 Mrd multipliziert ist der Startwert für den Generator. Das reicht für ca 1,5 Mrd Standorte .... -Bitte niemals auch nur drüber nachdenken, das für irgendwas Eindeutiges Timestamps geeignet sind (Sommerzeit und Winterzeit Umstellung ist die einfachste Problematik dabei, die kann man über utc lösen, aber auflösung in ms ist schon unter last sehr eng), unter Last sind 1000 Datensätze pro Sekunde nicht viel und der normale Timer insbesondere unetr windows hat eine wesentlich miesere Auflösung als 1ms. -Replikationskonflikte kann man asynchron nur dokumentieren, ähnlich wie Notes das macht. Auflösen kann man die mit Regeln (wer zuletzt speichert hat gewonnen oder ähnlich) -Inserts sind einfach zu replizieren, updates eher nicht: Einfaches Beispiel Artikellagerbestand, 2 Standorte verringern den um 1 und weil internet down ist weiss keiner vom anderen. Besser Insert in Bestandsveränderungstabellen lassen sich zeitnah zu einem Gesamtbestand konsolidieren, Startwert 10 vom zeitpunkt x, zugang +1 and zeitpunkt y standort a, zugang +5 and zeitpunkt z standort b usw, wenn alle Standorte repliziert sind kann man dann 10+1+6=16 zusammenrechnen auf dem führenden System und den Wert in die Tabelle schreiben und die Bestandveränderungen löschen . Dafür sollte die Datenbank 100% sauber Transaktionsfähig sein, sonst hast du eh nur datenmüll -Bei 2 Standorten ist die Problematik noch relativ simpel, wenn man erkennen will, das einer Offline ist, bei 160 Standorten ist es fast immer so, das irgendwo ein Router hängt, dsl tot ist, ein Bagger kabel aus dem Boden gerissen hat usw. Wichtig ist für unseren Kunden dabei, das an jedem Standort auch offline gearbeitet werden kann und sobald das wieder online geht, möglichst schnell repliziert wird. -Wir implementieren das mit Triggern, die immer dann wenn der replikationsuser was macht, inaktiv sind (das gilt für alle Trigger). Massenoperationen (delete from tab oder ähnliches) können direkt in eine Replikationslog Tabelle eingetragen werden, dann macht das der Replikationsuser an jedem Standort per skript ohne das es über die Leitung gehen muss -Wir bevorzugen lieber mehrere kleinere Tabellen als Monster mit hundetren Feldern -über die in Firebird existierende Technik execute statement on external können wir auch Blob Inhalte replizieren, die Technik eignet sich auch für synchrone transaktionechte Replikation -Lösungen wie ibreplicator versprechen mehr als sie halten, ob die in mysql eingebaute replikation was taugt weiss ich nicht, aber die war mal bekannt dafür das die nur funktioniert wenn die db komplett in den Arbeitsspeicher passt .... Bei uns hat die zentrale DB 290 GB und wächst täglich weiter, wäre also technisch anspruchsvoll, das im RAM zu haben ... -Für den Delphi Programmierer,der die Backoffice Anwendung dafür schreibt, ist das alles transparent, er muss sich nicht drum kümmern, was wann von wo nach wo geht. Das überwachen wir für den Endkunden automatisiert und wir verteilen auch Metadatenupdates über ibexpert Techniken, weil wir per reverse ssh tunnel auf jeden Standort direkt mit ibexpert kommen. Firebird läuft an fast allen Standorten unter linux, mit MSSQL basierender Replikation hätte der Kunde schon ohne Hardware 2-3 mio an Microsoft überweisen dürfen, die von uns gelieferte hardware/software kombination kostet keine 1000 € pro Standort. -Die Beschriebung geht wahrscheinlich weit über das hinaus, was du im Moment umsetzen willst, aber sicherlich helfen da einige Aspekte, vermeidbare Fehler eben auch nicht zu machen. Ansonsten viel Spaß bei der Umsetzung .... Gruß Holger |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Aber im Ernst, ich hab gerade Holgers Beitrag gelesen. Das "führende System" ist ein guter Ansatz. istzwar willkürlich aber erleichtert einiges. Gruß K-H |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
Und mit ein bisschen Fantasie ließe sich das in optimistic Locking verändern. Kann ja jeder so machen wie er will. Ich wollte ihm lediglich eine Möglichkeit unterbreiten. |
AW: Konzeptionelle Frage - Datenabgleich
Zitat:
|
AW: Konzeptionelle Frage - Datenabgleich
Die Idee hinter "nur einen Generator" ist ganz einfach.
Du kannst nur über die ID jeden Datensatz in der Datenbank identifizieren. Aber Tabelle+ID als Identifikator ist auch nicht ungewöhnlich. |
AW: Konzeptionelle Frage - Datenabgleich
Gegeben seien folgende Daten mit PK und FK. Wie sieht die Beziehung aus? Wer oder was hält Dich von einem Join ab, der gar nicht die richtigen Felder nutzt? Würde ein falscher Join wenigstens an einem lückenhaften Ergebnis sichtbar?
1 1 hobbycoder 2 2 himitsu 3 3 jobo 1 1 Köln 2 2 Bonn 3 3 Rom 1 1 ADV 2 2 BDV 3 3 CDV statt dessen diese Daten, so könnte man es besser finden: 1 11 hobbycoder 2 12 himitzu 3 13 jobo 4 1 Köln 5 2 Bonn 6 3 Rom 7 1 ADV 8 2 BDV 9 3 EDV Tatsächlich sähen sie wohl eher so aus: 1 11 hobbycoder 4 12 himitzu 7 13 jobo 2 1 Köln 5 4 Bonn 8 7 Rom 3 1 ADV 6 4 BDV 9 7 EDV Letztlich auch egal wie sie aussehen. Technische Schlüssel haben keine Bedeutung, außer ihrer Eindeutigkeit. Wenn man über Synchronisation usw. redet, eignen sich Sequenzen durch ihrere Konfigurierbarkeit außerdem, um in abgeschotteten oder nur teilweise Online Systemen autarke, aber ins Gesamtsystem passende ID zu generieren. Am Ende ist man vielleicht bei UUID. |
AW: Konzeptionelle Frage - Datenabgleich
IBEXPERT schlägt vor:
Design A: Einen eigenen Nummernkreis je Instanz und für jeden Datensatz eine Datenbankweit eindeutige ID. Meine Frage warum nicht folgendes: Design B: Einen eigenen Nummernkreis je Instanz und für jeden Datensatz eine inherhalb der Tabelle eindeutige ID. Von Himitsu weiß ich das in Design B die ID des Datensatzes dadurch eigentlich Tabelle+IDfeld ist. Ok. Aber muss ich nicht in jedemfall die tabelle wissen wenn ich die Datensynchronisieren will? Also spare ich mir ja nichts mit einer Datenbankweit eindeutige ID oder gar weltweit eindeutigen UUID. Oder liege ich irgendwie total daneben? Ich muss doch immer die information zu welcher Tabelle der Datensatz gehört mit in Verbindung mit der ID vermitteln. Oder nicht? |
AW: Konzeptionelle Frage - Datenabgleich
Ja, wisses musst du es, so in etwa.
Wenn die ID global ist und du sonst nichts hast, dann mußt du eben alle Tabellen durchsuchen, wo diese ID sich versteckt. Alternativ eine zentrale Tablelle, wo alle anderen Tabellen eine Referenz/Constraint drauf besitzen, den man Rückverfolgen kann. Wenn die Record-ID ein String ist, dann könnte man beim Generieren eventuell den Namen oder ID der Tabelle dort mit einbauen. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz