Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Metadaten für einzelne Datensätze

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von Tom.S, 17 März 2015.

  1. Tom.S

    Tom.S Fleissiger Benutzer

    Hallo,
    ich suche nach einer geeigneten Möglichkeit, einzelne Datensätze mit zusätzlichen Daten anzureichern.
    Beispielsweise habe ich eine Tabelle 'Firmenwagen'

    ID | Fahrer | Auto
    1 | Meier | Porsche
    2 | Müller | Jaguar
    ...

    und möchte folgendes erreichen:

    ID | Fahrer | Auto | eingetragen von | eingetragen am |
    1 | Meier | Porsche | A. D. | 03.02.2015
    2 | Müller | Jaguar | C. W. | 06.03.2015
    ...

    Das Problem an diesem naiven Ansatz:
    1) Ich habe hunderte Tabellen. Möchte ich wissen, wer als letzter etwas eingetragen hat, muss ich die Daten aus allen Tabellen auslesen.
    2) Es vermischt die Ebenen: Die konkreten Daten werden mit administrativen Daten verknüpft.

    Als Lösung sehe ich eigentlich nur eine große Tabelle "Eintragungen" mit einer Referenz auf die Datensätze. Mein Problem ist jetzt aber das Aussehen der Referenz: Korrekt wäre wohl eine große Tabelle zu erstellen und dann eine Kopplungstabelle für jede Tabelle zu erstellen. Das würde zwar die Daten sauber trennen, meine Tabellenzahl aber auf einen Schlag verdoppeln.
    Die etwas unsaubere, aber weit praktikablere, Lösung aus meiner Sicht wäre eine Tabelle mit folgender Struktur:

    ID | referenzierte_tabelle | id (referenzierte_tabelle) | eingetragen von | eingetragen am |
    79 | Firmenwagen | 2 | C. W. | 06.03.2015

    Jetzt würde ich gerne wissen, ob das so sinnvoll ist oder ob es noch eine bessere Lösung gibt. Und ich würde gerne wissen, wie man die Tabelle in PostgreSQL sinnvoll referenziert. Muss man den Tabellennamen nehmen oder gibt es eine PostgreSQL-interne Tabellen-ID, die auch nach einer Umbenennung der Tabelle erhalten bleibt?
     
  2. akretschmer

    akretschmer Datenbank-Guru

    Das ist aber eigentlich so ganz okay. Aber sehen wir mal weiter...

    Ist das jetzt praxisrelevant, daß Du wissen willst, wer als letztes in einer beliebigen Tabelle was eingetragen hat? Das erscheint mir jetzt, ehrlich gesagt, recht an den Haaren herbeigezogen.


    Es gibt sowas, die OID. Die kannst Du für jedes Objekt aus der pg_class Dir holen. Ich würde aber eher abraten, in User-Tabellen mit internen OID's zu arbeiten. Das fällt Dir spätestens dann auf die Füße, wenn Du einen Dump machst und diesen in einer anderen Umgebung (andere Version, andere schon vorhandenen Daten etc.) wieder einspielen willst. Don't do that!

    Um noch mal auf Deine erste Idee zu kommen: was spricht gegen einen TRIGGER, der in den relevanten Tabellen bei Insert/Update den Timestamp und den current_user einträgt?

    Oder aber einen Trigger auf den relevanten Tabellen, der ein zentrales Log führt. Hier noch eine fertige Lösung:

    http://andreas.scherbaum.la/blog/archives/100-Log-Table-Changes-in-PostgreSQL-with-tablelog.html

    Beachte dort auch den Kommentar #12 (von mir), der eine auch sehr nette und modernere/flexiblere Lösung als die von ads zeigt.
     
  3. Distrilec

    Distrilec Datenbank-Guru

    Und was hindert dich jetzt daran deiner Tabelle "Firmenwagen" zwei Spalten "modified_date" und "modified_from" anzuhängen?

    Zu 1: Wenn du wirklich so viele Tabellen hast... Ist die Aussage "Das ist der letzte User der IRGENDWO in der Datenbank etwas geändert hat" sowieso nicht möglich... Da es wahrscheinlich sekündlich ein neuer User sein wird... Es sei denn du brauchst diese Information wirklich nur ein paar Millisekunden...
    Zu 2: Das verstehe ich jetzt nicht... Wo ist denn da das Problem?
    Möglich? Ja... Sinnvoll ? Nein... Nach einer Woche ist deine Datenbank auf "mysteriöse Art und weise" auf die doppelte Größe herangewachsen... Weil wirklich jede Änderung mitgeschrieben wird und du für jede Änderung auch einen neuen Datensatz anlegt... Und da du nur sehr kostenintensiv entscheiden kannst welcher Datensatz gelöscht werden kann... Gibt es auch nur bedingte bis keine Möglichkeiten diese Tabelle in einer angemessenen Größe zu halten ohne Performance einbußen...


    Hängt natürlich auch davon ab, wieviele Datensätze deine Tabellen halten und wieviele User du hast...
     
  4. Tom.S

    Tom.S Fleissiger Benutzer

    Hallo Distrilec,
    es handelt sich um eine Datenbank, mit maximal 20 Benutzern, die alle paar Tage mal etwas eintragen.
    Die Größe der Datenbank ist also sehr begrenzt. Zentral ist aber eine Verifizierbarkeit der Daten und dazu zählen halt solche Metadaten für einen Eintrag.

    Hallo akretschmer,
    ja, war auch mein erster Gedanke. Sie sind zudem inzwischen auch als Depraced gekennzeichnet und scheiden auch deshalb als Möglichkeit aus.

    Mist, ich sollte meine Beispiele nicht immer so verkürzen: Es sollen nicht nur User und Timestamp eingetragen werden, sondern der User soll auch einen Kommentar zu dem Eintrag verfassen können. Deshalb fielen Trigger als Möglichkeit weg.

    Auch wenn mir da das Informatikerherz blutet, schaue ich mir die Möglichkeit, die Metadatenattribute einfach an jede Tabelle zu hängen mal näher an, wenn Ihr das auch so machen würdet.
    Danke für die Antworten.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden