[SQL allgemein] Tabellenverknüpfung, die bei Tabellen-Neuaufbau angepasst werden soll

[Gruselgockel]

Hallo,

ich versuche im Folgenden alles so einfach wie möglich darzustellen:

Habe zwei Datenbanktabellen, nennen wir sie A und B.

Tabelle A enthält persönliche Daten, Tabelle B enhält nachträglich eingegebene Userkommentare zu diesen Daten aus Tabelle A.

A schaut vereinfacht so aus:

• ID (Primärschlüssel)
  Name
  Vorname
  usw.

B so:

• ID (Fremdschlüssel)
  Username
  Kommentar
  usw.

Nun ist innerhalb des Projekts vorgesehen und von Natur aus sowieso nicht auszuschließen, dass die Tabelle A zu einem späteren Zeitpunkt komplett neu aufgebaut werden kann bzw. muss, womit sich auch die ID-Werte ändern können.

Wie bringt man es nun am Einfachsten und zugleich Sichersten hin, dass die Fremdschlüssel ID in Tabelle B auch nach dem Neuaufbau von Tabelle A wieder auf die zugehörigen Datensätze in A zeigen?

A enthält zwar einige einigermaßen individuelle Felder wie Geburtsdatum, -zeit usw., jedoch keine, die die Eindeutigkeit perfektionieren, wie z.B. Adresse, Email-Adresse, Tel. o.ä.

Man kann nun natürlich alle bzw. zumindest alle weitgehend individuellen Felder von A nach B kopieren und dadurch nachträglich die Zugehörigkeit bestimmen, aber erstens ist das natürlich ziemlich speicherintensiv und zweitens auch nicht bombensicher (z.B. durch mögliche "Doppelgängereigenschaften", die man vielleicht nicht gleich erahnt, weil es in den den Datensätzen wie gesagt keine Eigenschaften gibt, die als identifizierend angesehen werden können, nicht mal in Kombination, womit falsche Zuweisungen immer noch nicht ausgeschlossen sind).

Eine breite Prüfsumme über alle Felder wäre zwar nicht ganz so speicherintensiv, jedoch auch noch nicht geeignet, um falsche Zuweisungen sicher auszuschließen.


Vielleicht gibts ja eine saubere, risikofreie und nicht so aufgeblähte Lösung auch, bei der dann jeder Kommentar aus B wieder dem richtigen Datensatz aus A zugewiesen werden kann?


Gruß Michi

[Abraxax]

dass die Tabelle A zu einem späteren Zeitpunkt komplett neu aufgebaut werden kann bzw. muss

nenne mir mal bitte einen grund, warum man das machen sollte .....

ansonsten hast du ja o.g. problem ....

[Gruselgockel]

Hi Abraxax,

Original geschrieben von Abraxax
nenne mir mal bitte einen grund, warum man das machen sollte .....

Z.B. eine unüberlegte Manipulation an der Datenbank, die nicht rückgängig gemacht werden kann und schon muss die Datenbank neu aufgebaut werden. Fehler können nun mal passieren.

In der Zwischenzeit kann sich die Datenquelle jedoch bereits geändert haben, sodass es nicht gesichert ist, dass aus Datensatz Nr. X in der Quelldatei wieder Datensatz ID=X in der Datenbank wird.

Ich kann zwar nicht behaupten, dass so ein Fall schon mal aufgetreten wäre, weil ich üblicherweise schon überlege, was ich wohin schreibe, aber für den Fall eines intellektuellen Aussetzers...? Angenommen, ich hau aus Versehen irgendwo ein DROP TABLE... rein, was dann? Ok, bei Alkohol natürlich Hände Weg von Datenbank und Skripten, aber irgendwie kann so was ja mal reinrutschen.

Original geschrieben von Abraxax
ansonsten hast du ja o.g. problem ....

In Kombination mit einer adäquaten Lösung wär das ja nicht weiter tragisch.

Hm, vielleicht besteht die beste Lösung ja darin, dass man den Primärschlüssel zugleich noch mit in die Quelldatei aufnimmt?
Dann kann eigentlich nichts mehr schiefgehen... bzw. dann kann ruhig was schiefgehen, aber die Daten lassen sich dennoch wieder korrekt zuordnen?

Gruß Michi

[ghostgambler]

wie wäre es bei dir mit dem Gin zum Frühstück zusätzlich noch einen Cronjob laufen zu lassen, der die ganze DB als .tar.gz auf den Server zippt, am besten mit dem aktuellen Datum als Filename, so hast du ganz viele Wiederherstellungspunkte .... mal ehrlich, so eine scheiß Begründung, für soviel unnützen Aufwand habe ich seit ner halben Ewgikeit nicht gehört ... nein, habe ich noch nie gehört -.-

ggf. Binlog und das gzippen, aus dem kompletten Binlog kann man später die Tabellen neu basteln, aber da ist fast die Lösung mit dem täglichen Cron besser und man sollte ja eh ab und an mal ein Backup seiner DB irgendwo hin sichern...

[Gruselgockel]

Gebackupt wird auch bei uns regelmäßig und ich habe auch nicht bezweifelt, dass es wahrscheinlich nie nötig sein wird, die Datenbank komplett neu aufzubauen. In den meisten Crash-Fällen wird man sich natürlich bereits über das simple Restoren eines Backups helfen können und den Rest ggf. per Hand erledigen.

Weiterhin will sich der Projektverantwortliche Änderungen an der Datenbankstruktur vorbehalten und vielleicht ist es bei größeren Umbauaktionen dann doch mal einfacher, die Datenbank mal wieder neu aufzubauen.

Über Sicherheitsrisiken und den Sinn von Vorsorgemaßnahmen kann man doch ewig spekulieren und diskutieren... Braucht man eine Invaliditätsversicherung oder braucht man sie nicht. Sollte man eine kapitalbindende Rentenversicherung abschließen, die Ersparnisse besser in Aktien anlegen oder alles unterm Kopfkissen verstauen. Verhindert der Airbag beim Crash Schlimmeres oder knallt er einem frontal gegen die Rübe. usw. Spekulier spekulier. Da kann man doch jedem seine eigene Meinung zugestehen? Und ich bin eben der Meinung, dass es dann, wenn es mal der einfachere oder gar einzige Weg sein sollte - wie wahrscheinlich das auch sein mag -, die Datenbank neu aufzubauen, gut und richtig gewesen sein wird, eine Maßnahme zur Ermöglichung dafür getroffen zu haben, wenn der Aufwand dafür ein geringer war.

Ich kann nicht 100%ig abschätzen, OB und WANN genau es mal nötig sein wird, die Datenbank neu aufzubauen... Wahrscheinlich nie.
Ich war ja lediglich mal am Überlegen, ob und wie es sich mit nicht zu viel Aufwand hinbekommen ließe, dass man ggf. die Datenbank mit den richtigen Verknüpfungen einfach neu aufbaut. Und wenn es eine Lösung gibt, die mit nicht zu viel Aufwand verbunden ist, dann spricht doch nichts dagegen, den Gebrauch von dieser sicherheitshalber mal zu ermöglichen?

[Abraxax]

einzig und allein der oben angesprochene export via cron ist die lösung.

und wenn du mit einem täglichen backup nicht klar kommen solltest, kannst du den cron auch (halb)stündlich laufen lassen.

aber mal im erst ... dein vorhanben entzieht sich jeder logik.