Aufbau Tabelle - MySQL (allgemein)

k3nguruh

k3nguruh

Erfahrenes Mitglied
Hallo,

ich bin auf der Suche nach einer Lösung für folgendes Problem:

Tabelle (gekürzt)

Code: 
           Primary
persID (Auto) | code | vorname | nachname | gebdatum | plz | ort .....
1000          | .... | ....... | Müller   | .......

Die Spalten - Namen sollten erstmal selbsterklärend sein.

Nun folgendes: Max Müller hat seinen Nachnamen zum Bsp. durch Hochzeit in Meier geändert.

Wie würdet ihr / sollte man vorgehen, wenn die Person ihren nachnamen ändert, ich aber auch den alten nachnamen noch vor der Änderung für andere Ausgaben benötige?

Ich habe mir jetzt überlegt, die Änderung in der Haupttabelle zu speichern und dann in einer Neuen Tabelle die alten Daten zu speichern, die ich dann jedesmal mit Joinen muss.

Update
Code: 
persID | code  | vorname | nachname | gebdatum | plz | ort .....
1000   | ..... | .....   | Meier    | .......

Und dann die neue Tabelle mit

Insert
Code: 
persID | spalte   | text   | zeitstempel
1000   | nachname | Müller | timstamp

oder ???

ich würde mich über Vorschläge freuen
 
Würde ich nicht machen.
Einfach zusätzlich Spalte "NachnameAlt" und dann einfach bei Änderung fortschreiben.
Muss natürlich vorher ausgelesen werden.
Trigger geht glaube ich nicht, weil MySQL keine rekursiven Trigger erlaubt (Trigger für Update auf dieselbe Tabelle, welche dann wieder ein update erfährt)
 
Hmmm......unwahrscheinliches Szenario (10 mal heiraten? Alter schwede *gg*), aber na gut.
Variante 1
Zusätzliche Tabelle „Nachname„ in 1 zu n Beziehung. Würde noch ein Datumsfeld hinzufügen „gültig ab“
Abfragen kannst du dann entweder über das Datumsfeld, oder etwaige andere Datensätze haben einen direkten Fremdschlüssel auf die Nachnamenstabelle

Variante 2
Behandle die Person wie eine neue Person, jedoch sollte dann „persid“ nicht Auto-increment sein.
bei Namenswechsel würdest du einfach einen neuen Satz erzeugen (kopiere/blende alle anderen Felder vor ausser Nachname)
ergo: am besten anonymen automatischen primärschlüssel.
Ja, du hast dadurch Redundanz, die Abfragen wären aber um einges einfacher
 
Hallo,

Variante 2: meinst du in etwa so?

Code: 
       Primary      Index
id (Auto) | code | persID | vorname | nachname | .... | zeitstempel
1000      | .... | 1000   | ....... | Müller   | .... | NULL
1001      | .... | 1000   | ....... | Meier    | .... | 2020-12-09
 
Japp. genau so.
Etwaige Detail-Sätze, welche darauf zugreifen, haben als Fremdschlüssel das Feld ID, deine Abfrage filterst du aber über das Feld PersID.
Dadurch bekommst du für deine "Historie" immer den korrekten Personensatz zugewiesen, da du ja in der Abfrage "ID" mit dem Fremdschlüssel gleich setzst.
Aircode
SQL: 
SELECT *
FROM Historie, Person
WHERE
Person.ID=Historie.Person_ID AND
Person.PersID=1000
 
Hier verstehe Ich nicht, warum man den alten Nachnamen noch für andere Ausgaben benötigt?!

Wie Zvoni auch schrieb, kannst du es anhand einer Historie-Tabelle machen.
Wir speichern zum beispiel nur den letzt geänderten Nachnamen.
Wenn er in deinem Beispiel 10-mal Heiratet, dann wird nur der letzte und der Neue gespeichert.
Der Rest ist am Ende uninteressant.

Ich wüsste jetzt auch gar nicht, warum man noch den alten Nachnamen speichern sollte, wenn man einen unique ID hat oO
 
EC, Stichwort "DataWarehouse"
Es gibt schon Gründe, warum man alte "Details" in der Historien-Ausgabe haben möchte.
Nachname ist vielleicht ein schlechtes Beispiel, aber nimm mal anstatt Nachname "Adress-Änderung" und schon wirds vielleicht klarer
 
Zvoni hat gesagt.:
EC, Stichwort "DataWarehouse"
Es gibt schon Gründe, warum man alte "Details" in der Historien-Ausgabe haben möchte.
Nachname ist vielleicht ein schlechtes Beispiel, aber nimm mal anstatt Nachname "Adress-Änderung" und schon wirds vielleicht klarer
Zum Vergrößern anklicken....
Daher meinte Ich dass dann eine Historie mehr sinn macht. :)
Man sollte eventuell auch betrachten, wie lange man dann die Daten benötigt. :)
 
Stimmt, aber dafür kennen wir zu wenig Details.
Ich habe das gleiche Thema bei der Software, welche ich für unseren Fallschirmspringerverein derzeit konzipiere, und de facto benutze ich Variante 2 für das Konzept, weil alle alten Detailsätze nicht mehr geändert werden (sollen/dürfen).
In meinem Fall, Schülersysteme (welche aus 4 Komponenten bestehen), bei welchen im Laufe der Zeit Komponenten getauscht werden (Anderer Hauptschirm usw.), jedoch die Historie erhalten bleiben muss, welche Komponente wann wo verbaut war.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück