Datenintegrität

[Wasser_Wanderer]

Hallöchen zunächst.

Ich hoffe das mein Thread-Titel richtig gewählt wurde.

Folgende Aufgabe/Problem stellt sich mir:

1. Eine ID ist unverwechselbar

aber was ist wenn hinter dieser ID wechselnde Bezeichner stecken?

Ein Beispiel (nur Exemplarisch):
Personalausweis-Nr = ID (Unique)
Tabelle name:
ID / Name
1 / Müller

So nun folgendes Szenario:

ID 1 strickt im DamenClub "Stricke" bis 01.01.2014 danch kegelt sie beim KegelClub "GutHolz".

Sie heiratet am 15.05.13 und heißt nun Schmidt. Oder Sie lässt sich 5 Wochen später wieder scheiden und nimmt ihren Mädchen Namen: Hinz, an.
Oder sie heiratet wieder und heist dann Meyer.

Nun folgt mein Problem:
Wenn ich ihren Namen ändere, änder ich auch alle Verknüpfungen dazu.

Aber das möchte ich nicht.

Bedeutet, ich möchte ihren Namen zum Club, egal wann und wie sie hieß haben.

Wenn ich nur den Namen ändere, dann fehlt mir der Bezug zum Club wo sie anders hies.

Irgendwo muss ich als "Schattentabelle" alle Namensänderungen wohl abspeichern.

Zusammengefasst:
Der aktuelle Name soll in der Clubtabelle stehen bis zum Austritt aus dem Club.

Das könnte per TRIGGER geschehen. Aber ist das sinnvoll?

Wie würdet ihr diese Aufgabe lösen?

Ich hoffe mein Problem darstellen zu können.

Freue mich auf eure Anregungen.

[Kropff]

Man nimmt dafür niemals veränderbare Daten. Das geschieht immer immer über eine eindeutige Zuordnung. Also zum Beispiel ein PRIMARY KEY mit AUTO_INCREMENT. Details dazu findest du hier.

Peter

[Wasser_Wanderer]

Hallo Peter,
zunächst Danke für deine Antwort.

Ich kenne deine HP und nutze sie oft wenn ich Dinge nachlesen möchte

Vielleicht habe ich mich undeutlich in der Thread-Erstellung ausgedrückt:

ID ist immer Unique und Autoinkrement. Das ist mir klar.
In meinem Beispiel aber, könnte sich der Name zu der ID ändern durch Heirat, Geschlechtsumwandlung was weis ich.

Und genau DAS ist meine gedankliche Problemstellung.

Die ID tauscht in verschiedenen Clubs hat auf.
Die ID ändert unregelmäßig seinen NAMEN (nicht die ID-Nr)

Wie gehe ich damit um, damit in den Clubs immer der zu der Zeit aktuelle Name stehen bleibt? Und NICHT der Name der jetzt aktuell ist?

Und woher weis ich (History) das Müller mal Schmidt oder Hinz war?

Gruss WW

[combie]

Und woher weis ich (History) das Müller mal Schmidt oder Hinz war?

In dem du solche veralteten Einträge nicht löscht, sondern einen aktuelleren anlegst. Damit du dann herausfinden kannst, welcher der frischeste ist, könntest du diese alle mit einem Zeitstempel versehen.

Ansonsten sei dir folgendes ans Herz gelegt:
A Visual Explanation of SQL Joins
SQL und relationale Algebra
Die 5 Normal Formen

[Wasser_Wanderer]

Hallöchen combie,
danke das du dich auch mit eingeschaltet hast

Ich denke jetzt habe es verstanden und würde es so dann lösen:

Table_Aktuell:
ID(Auto_Incr) / Name
1 / Müller

und per TRIGGER:

Table_History
ID(Auto_Incr) / ID / Name / Datum (änderung)
1 / 1 /Schmidt / 2013-05-15

So müsste es dann gehen?

P.S. Deine Links sind auch Klasse combie

[Yaslaw]

Es geht dabei um das Problem "Aktuelle Einträge pro Gruppe auslesen"
Yaslaw.Info: [MySQL] Aktuelle Einträge pro Gruppe auslesen
Dabei musst du nur nach dem Datum filtern wo der Name ausgelesen werden soll.

Als Key solltest du die ID (nicht mher autinkrement) und das Datum nehmen.

[Wasser_Wanderer]

Hallöchen Yaslaw.
auch dir danke das du dich einbringst.

Als Key solltest du die ID (nicht mher autinkrement) und das Datum nehmen.

Hmm.... sollte nicht jeder Datensatz eine eindeutige ID haben?

Deshalb dachte ich es ja so:

Table_History
ID(Auto_Incr) / ID(User-ID) / Name(User-Name)/ Datum (änderung)
1 / 1 /Schmidt / 2013-05-15

Oder ist das in meinem Fall zu vernächlässigen?

Deinen Link Yaslaw, hab ich natürlich sofort als Lesezeichen gespeichert

[mermshaus]

Interessantes Thema.

Als Key solltest du die ID (nicht mher autinkrement) und das Datum nehmen.

Das würde ich spontan allerdings nicht machen, da die ID dann redundant abgelegt wäre. (Ich hoffe, die Aussage ist nachvollziehbar.)

Du gehst ja glaube ich davon aus, dass sämtliche Felder veränderlich sind. (Ist als Annahme aber meines Erachtens völlig akzeptabel.)

Ich würde dennoch eine Pro-forma-Tabelle erstellen, die im Zweifel wirklich nur die IDs von Personen enthält, damit ich in der eigentlichen Datentabelle dann einen Fremdschlüssel setzen und sozusagen Redundanz vermeiden kann.

Anders gesagt: Ich finde die Darstellung in Wasser_Wanderers letztem Post ganz passend.

Beim Abruf der aktuellen Daten eines Nutzers müsste man dann ja dennoch ein „group-wise maximum“ bilden. Ich weiß nicht, wie effizient das ist. Es wäre ja auch noch möglich, in der „echten“ Personen-ID-Tabelle den jeweils aktuellen Eintrag einer Person in der Daten-Tabelle zu verlinken. Das wäre allerdings dann doppelt verkettet, da der Daten-Eintrag ja auch auf die ID der Person verweist. Ich weiß nicht, ob man so was in Datenbanken macht. Vielleicht eher über eine weitere Verknüpfungstabelle?

Recherche und Hintergründe dazu würden mich auch interessieren.