Datenintegrität

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Datenintegrität

    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.

  • #2
    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
    Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
    Meine Seite

    Kommentar


    • #3
      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

      Kommentar


      • #4
        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
        Wir werden alle sterben

        Kommentar


        • #5
          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

          Kommentar


          • #6
            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.
            item: Ich habe es mir aus gesundheitlichen Gründen abgewöhnt unformatierten Code zu lesen (Auch SQL-Statements kann man formatieren!)

            Kommentar


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

              Zitat von Yaslaw Beitrag anzeigen

              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

              Kommentar


              • #8
                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.
                Zuletzt geändert von mermshaus; 10.06.2013, 05:24.

                Kommentar

                Lädt...
                X