[SQL allgemein] Protokollierung von Änderungen

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

  • [SQL allgemein] Protokollierung von Änderungen

    Guten Morgen,
    ich bräuchte mal eine Idee, wie ich jegliche Änderungen in einem System aufnehme.

    Es existiert eine Tabelle 'meldung', in der die Daten eines bestimmten Falles hinterlegt sind (z.B. Abteilung, Priorität, Status, Beschreibung, etc.). Dann gibt es eine Tabelle 'user_bearbeitet_meldung', die lediglich aus der meldung_id, der user_id und einem Datetime besteht. Ausserdem ist logischerweise eine User-Tabelle vorhanden.
    Nun möchte ich wie gesagt protokollieren, wann wer was geändert hat, jedoch weiß ich nicht, wie ich das am sinnvollsten bewerkstellige.

    Meine erste flüchtige Idee war, dass ich die Daten aus der Tabelle 'meldung' mit einer änderungs_id versehe, was aber sicherlich die Größe der DB potenzieren wird. Was könnt ihr mir empfehlen??

  • #2
    ich würde in der tabelle meldungen nur eine meldung_id, eine beschreibung, die priorität nach meinung des users und den zeitpunkt des anlegens speichern

    dann machst du eine weitere tabelle meldungen_verlauf mit den feldern:
    meldung_id
    bearbeitender_user_id
    status_id
    weitere_beschreibung
    bearbeitet_am
    neuer_bearbeiter_id
    prioritaet_id

    dann noch zwei tabellen für die staus und die prioritäten aus denen gewählt werden kann (um kreativen ergüssen der user vorzubeugen)

    falls ein user mehrere typen von meldungen bearbeiten sollte, die nichts miteinander zu tun haben (konfiguration von office-anwendungen und beantragen von mailaccounts bspw.) dann solltest du eventuell noch entsprechende arbeitsgruppen einführen und in den tabellen meldungen und meldungen_verlauf immer mitführen

    natürlich wird die db dadurch größer, aber du kannst nicht mehr ionformationen speichern ohne mehr platz zu verbrauchen *g*
    Ich denke, also bin ich. - Einige sind trotzdem...

    Kommentar


    • #3
      Re: [SQL allgemein] Protokollierung von Änderungen

      Original geschrieben von miguel_rkc

      Nun möchte ich wie gesagt protokollieren, wann wer was geändert hat, jedoch weiß ich nicht, wie ich das am sinnvollsten bewerkstellige.
      wenn du die bisherige Struktur nicht großartig ändern willst
      - in Tabelle meldung 2 Spalten: dt_last_change (datetime) und user_id (int), somit hast du wer, wann erfasst/geändert. (Oder in user_bearbeitet_meldung eine Spalte dt_last_change (datetime) zusätzlich)
      - für was wird kompliziert. Du musst dafür eine Extratabelle (meldung_historie) mit identischer Struktur plus 2 Spalten: dt_history (datetime) und meldung_id anlegen. Vor jeder Änderung musst du den existierenden Datensatz in diese Extratabell mit einer datetime-Eintrag in dt_history ablegen. Dabei musst du wirklich prüfen, ob überhaupt was geändert wurde, ob das aber sinnvoll ist ... ... IMHO nicht

      **verschieb zu BS**
      Zuletzt geändert von asp2php; 27.09.2004, 10:05.

      Kommentar


      • #4
        Re: Re: [SQL allgemein] Protokollierung von Änderungen

        Original geschrieben von asp2php
        somit hast du wer, wann erfasst/geändert
        doch nur denjenigen, der zuletzt geändert hat oder?

        ich finde die idee mit den "arbeitsgruppen" und der tabelle meldungen_verlauf toll, aber ich bin da nicht unbedingt objektiv*g*
        ist vielleicht auch die kanone für seine spatzen...


        danke für's verschieben, ich wusste, ich hatte was vergessen
        Ich denke, also bin ich. - Einige sind trotzdem...

        Kommentar


        • #5
          Also wenn ich 'meldung' mit einem Datum und einer user_id versehe, dann kann ich mir im Grunde genommen ja die user_b_meldung-Tabelle sparen.

          Also die Frage, ob die Protokollierung Sinn macht oder nicht, möchte ich mal unbewertet lassen, da es einfach eine Anforderung ist, die erfüllt werden muss - lediglich die Methode ist diskussionswert. Da ihr beide aber den gleichen Gedanken hattet und ich euch einfach mal vertraue (^^), scheint an der fast-"Spiegelung" von 'meldung' kein Weg vorbei zu führen.

          Danke für das kleine Brainstorming, wobei weitere Vorschläge natürlich ergänzt werden können.
          Zuletzt geändert von miguel_rkc; 27.09.2004, 10:16.

          Kommentar


          • #6
            ist doch keine spiegelung

            du könntest aber die tabelle meldungen weglassen und alles in meldungen_verlauf speichern

            einträge, bei denen die bearbeiter_id NULL ist, sind noch nicht zugewiesen und sollten bei allen usern, die der entsprechenden gruppe zugewiesen sind auftauchen, aber das wäre dann auch etwas komplexer
            Ich denke, also bin ich. - Einige sind trotzdem...

            Kommentar


            • #7
              Re: Re: Re: [SQL allgemein] Protokollierung von Änderungen

              Original geschrieben von mrhappiness
              doch nur denjenigen, der zuletzt geändert hat oder?
              nein, weil:
              Du musst dafür eine Extratabelle (meldung_historie) mit identischer Struktur plus 2 Spalten
              somit hast du den letzten bearbeiteten User und alle seine Vorgänger . Naja, nicht schön gelöst, aber wenn er die bisherige Struktur nicht sehr viel ändern möchte ....

              Kommentar


              • #8
                Es soll auf keinenfalls an dem Aufwand der Strukturänderung scheitern! Also wenn du eine weitere Idee hast, dann raus damit.

                @mrhappiness: Naja, fast gespiegelt, da die Spalten, die nicht geändert wurden ja identisch mit dem vorherigen, dazugehörenden, Tuple sind.

                Kommentar


                • #9
                  dann lies dir meinen ersten post und den über deiner antwort nochmal durch

                  da hättest du eine tabelle mit allen relevanten informationen, schön normalisiert und siehst auch wer wann was gemacht hat und an wen das problem weitergeleitet wurde

                  was soll das ding denn eigentlich alles können?
                  auch workflows zu standardtätigkeiten, so dass man dem benutzer auskunft geben kann, wo's gerade hängt?

                  oder schösse man damit über's ziel hinaus?



                  naja, ich find meinen vorschlag toll, asp2php hat ja im prinzip das gleiche vorgeschlagen (zwei dumme, ein gedanke ), kannst ja mal abwarten was sonst noch so an meinungen kommt und dir überlegen, was das system genau alles können soll
                  Ich denke, also bin ich. - Einige sind trotzdem...

                  Kommentar


                  • #10
                    Ich glaube ich habe schon verstanden warauf du hinaus willst, jedoch ist eine User-Gruppierung (durch Abteilungszugehörigkeit) bereits vohanden und der andere Punkt, den du angesprochen hattest, ist durch den Status (offen, läuft, geschlossen) der Meldung gelöst. Jeder User einer Abteilung sieht standardmäßig nur die Meldungen, die seiner Abteilung zugeordnet sind.

                    Ich werde mal das was ich bisher gemacht habe hochladen, dann könnt ihr euch sicherlich ein besseres Bild davon machen.

                    *edit*:

                    Wie wäre es eigentlich, wenn ich die user_bearbeitet_meldung-Tabelle bestehen lasse und sie durch eine Spalte aktion (o.ä.) ergänze. In die Tabelle schreibe ich dann einfach rein was geändert wurde (Stilsicherung übernimmt hierbei php).

                    z.B.

                    user_id: 1
                    meldung_id: 23
                    datum: 2004-12-12 12:12:12
                    aktion: 'Status von "offen" auf "laeuft"<br>Benutzer von "Herr Maier" auf "Herr Meier"'

                    Wie sieht das eigentlich aus, ist es sinnig, bzw. "erlaubt" html-Befehle in einem String zu hinterlegen?
                    Zuletzt geändert von miguel_rkc; 27.09.2004, 10:55.

                    Kommentar


                    • #11
                      Original geschrieben von miguel_rkc
                      ist es sinnig, bzw. "erlaubt" html-Befehle in einem String zu hinterlegen?
                      erlaubt: ja
                      sinnig: meiner meinung nach nein, da du dir eventuell später nötige layoutänderungen dadurch erschwerst

                      ich würde auch den status nicht als text in die tabelle schreiben.
                      was, wenn sich jemand vertippt und statt offen ofen als status angibt?

                      jetzt such diese meldung mal, bei den offenen meldungen wirst du sie nicht finden
                      Ich denke, also bin ich. - Einige sind trotzdem...

                      Kommentar


                      • #12
                        Sowas wird ja nicht passieren, da das Webinterface in diesem und ähnlichen Fällen ein Drop-Down-Menü zur Verfügung stellt.

                        Mit der Layout-Änderung geb ich dir recht, allerdings wird diese definitiv nicht vorgenommen werden.

                        Kommentar


                        • #13
                          wenn es sowieso ein formular mit fest vorgegebenen werten gibt, dann solltest du das imho auch im datenmodell entsprechend reflektieren, als stichwort sei hier mal normalisierung in den raum geworfen
                          Ich denke, also bin ich. - Einige sind trotzdem...

                          Kommentar


                          • #14
                            Stichwort Datenmodell, hier ist es:



                            So müsste es euren ersten Gedanken entsprechen. Verstößt die Anhangsgeschichte eigentlich gegen eine Normalform?
                            Zuletzt geändert von miguel_rkc; 28.09.2004, 11:22.

                            Kommentar


                            • #15
                              Ok, ich habe die Problem jetzt ein wenig anders gelöst.

                              user_bearbeitet_meldung wurde durch die spalte 'aktion' ergänzt. Wenn jemand nun eine Meldung editiert, wird mittels einiger Abfragen das 'von' und 'auf' ermittelt und in die Datenbank eingetragen (mittels einer einfachen Liste).

                              Nach langer Überlegung schienen mir eure Gedanken zwar sinnig, aber ein wenig zu Ressourcenlastig und ein kleines bisschen zu aufwändig.

                              Dennoch ein großes DANKE für das kleine Brainstorming.

                              ps: seht euch mal bitte das (mittlerweile wieder veraltete) Datenmodell an und sagt mir, ob ich 'meldung_h_anhang' gegen eine Normalform verstößt, oder ob es so i.o. ist.

                              Kommentar

                              Lädt...
                              X