Announcement

Collapse
No announcement yet.

Datenbankdesign

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Datenbankdesign

    Hallo zusammen,

    Ich habe eine Design Frage. Ich habe ein java Program geschrieben mit der ein User Personen in einer DB speichern kann. Jetzt will ich eine Art Änderungsprotokoll in einer Tabelle speichern, damit z.B. ein Admin später nachverfolgen kann was bei einer Person geändert wurde.

    Allerdings habe ich keine Ahnung wie die Tabelle(n) aussehen soll, mein erster Ansatz ist dass ich alle Eigenschaften die sich geändert habe in EINER Spalte speichere, getrennt durch z.B. ein * oder ein abstrakteres Zeichen. Genauso mache ich es dann mit den Werten der Eigenschaften(in einer spalte die neuen Werte, in einer die alten). So würde ich eine Zeile pro Änderung bekommen (natürlich noch mit datum versehen etc...), auch wenn sie mehrere EIgenschaften der Person ändern.

    Allerdings finde ich diesen Ansatz nicht gut, da meine Tabelle ja dann nicht mal Normalform 1 erfüllt, außerdem hab ich ein Stringgefummel, geschweige denn den Fall der User gibt mal einen Wert mit * ein.

    Mein zweiter Ansatz war zwei Tabellen. Eine die pro Änderung eine Zeile enthält (mit datum, user etc..) und eine zweite die für jede Eigenschaft die sich geändert hat eine zeile anlegt. Die zwei Tabellen würde ich dann verknüpfen (fremdschlüssel und so)
    Allerdings hab ich da die Befürchtung dass die Tabelle schnell zu groß wird. Besonders da ich die Daten über 1 oder 2 Jahre speichern will.

    hat jemand ne Idee?
    Vielen Dank + beste Grüße
    OhNo

  • #2
    Hi,

    leg dir eine Tabelle an, die genauso aussieht wie die ursprungstabelle plus den von dir gewünschten Informationen wie Datum, User etc.

    Bei jeder Änderung selektierst Du vor der eigentlichen Änderung den alten Datensatz heraus und speicherst ihn mittels INSER INTO in deiner Logtabelle.

    Das kann z.B. über einen Trigger erledigt werden oder idealerweise über deine Speicherlogik.

    Allerdings hab ich da die Befürchtung dass die Tabelle schnell zu groß wird. Besonders da ich die Daten über 1 oder 2 Jahre speichern will.
    Von wievielen Millionen Einträge reden wir denn? Ansonsten passt die Beschreibung "groß" nicht so ganz. Datenbanken wurden dafür gemacht große Datenmengen zu verwalten.

    Dim
    Zitat Tom Kyte:
    I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

    Comment


    • #3
      Hi,

      erstmal danke für deine Antwort. Das Problem bei der ganzen Sache liegt jetzt noch daran dass ich so ein Protokoll auch für andere Tabellen nutzen will (die z.B. "Projekte" denen die Personen zugeordnet werden, speichert). Um nicht für jede einzelne Tabelle eine eigene Log Tabelle erstellen zu müssen, will ich nen möglichst generischen Ansatz wählen.

      Hast du da eine Idee dafür? Wäre der zweite Ansatz dafür eine Lösung oder fällt dir was besseres ein?
      Danke Vielmals
      Greetz
      OhNo

      Comment


      • #4
        Hallo,

        Der Ansatz für jede Tabelle eine Log-Tabelle zu haben ist auch aus meiner Sicht gut. Hat man mehrere Änderungen am Datensatz gemacht, so könnte man mit einer einfachen Anfrage für diese Tabelle feststellen, was, wann und in welcher Reihenfolge geändert wurde.

        Wählt man eine Tabellen übergreifende Lösung, so muss man sich folgende Fragen stellen:
        - Wie heißt die Tabelle mit dem Datensatz, der geändert wurde?
        - Wie heißt die geänderte Spalte?
        - Welchen Datentyp hat die Spalte? (für mögliche spätere Verarbeitung nötig)
        - Wie ist der neue Wert? (z.B. als Text speichern, später Cast bei Verarbeitung)
        - Wie lautet der Primärschlüssel der geänderten Tabelle? (damit man den Datensatz findet)
        (bei mehrspaltigem Primärschlüssel ist eine extra Tabelle erforderlich mit Spaltenname und Wert)

        Nicht zu verachten ist der Programmier- und Organisationsaufwand bei der Auswertung dieser Log-Daten.
        Außerdem hat man ein mögliches zeitliches Problem bei Abfrage und Aufbereitung bei der zentralen Lösung, da alle Änderungen in einer, bzw. zwei Tabellen für das Log anfallen.

        Letzter Hinweis:
        Bei beiden Lösungen könnte man programmtechnisch steuern, ob ein Log erfolgen soll oder nicht.


        Schöne Grüße

        A. Fuss

        Comment

        Working...
        X