Ankündigung

Einklappen
Keine Ankündigung bisher.

Daten automatisch archivieren

Einklappen

Neue Werbung 2019

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

  • Daten automatisch archivieren

    Hallo,

    ich schreibe grade eine Art Arbeitszeit-Erfassungstool. Dieses wird im Laufe seiner Einsatzzeit sehr sehr viele Datensätze speichern - das ist auch so gewollt.
    Mir geht es nun aber darum, dass z.B. nach 5 Jahren die Datenmenge sehr groß ist, schließlich werden keine Daten gelöscht.

    Ist es da sinnvoll evtl. ältere Datensätze zu archivieren und wenn ja, wie implementiert man das so Userfreundlich, dass die Daten leicht archiviert und auf Userwunsch schnell wieder zur Verfügung stehen.

    Ich weiß, dass man z.B. über das Datenbankinterface die Datenbank importieren und exportieren kann (um z.B. Backups zu erstellen). Ich möchte aber dem user (falls eine Archivierung von Vorteil ist) die Möglichkeit bieten z.B. alle Datensätze die älter sind als 10.05.2010 zu archivieren und bei Bedarf trotzdem drauf zugreifen zu können - die Daten also temporär wieder geladen werden...
    ...oder macht das keinen Sinn??

  • #2
    Überleg Dir halt, wie Du gern mit der Software arbeiten würdest.
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #3
      Da gibt es wie immer verschiedene Möglichkeiten und Du musst Dir Deine liebste Variante selber validieren und aussuchen.

      Zum Einen wäre zu klären, was "sehr sehr viele Daten" sind, dann als Ideen:

      a) CREATE TABLE ... PARTITION .... (nach Jahr)

      b) Pro Jahr eine Tabelle

      - die aktive Tabelle ... z.B. zeit_daten
      - die archivierten Daten pro Jahr in eine Tabelle zeit_daten_2009 etc.

      - Mit einem VIEW über alle zeit_daten - Tabellen sind alle Daten wieder "am Stück" verfügbar.

      Grüße
      Thomas

      Kommentar


      • #4
        Es werden viele Datensätze, da z.B. jeder Mitarbeiter täglich einträgt was er/sie wann, für welches Projekt, für welchen Kunden wie lange gemacht hat. Im Prinzip werden in der Datenbank "nur" strings gespeichert und ich weiß, dass der MySQL-Zugriff sehr schnell ist trotz einer großen Datenmenge. Mir macht die Verarbeitung der Daten via PHP nur große Sorge.

        Dazu muss ich evtl. noch erklären, dass die Funktionen für die Datenbankzugriffe nicht von mir geschrieben sind, ich sie auch nicht ändern kann und ich auf der Datenbank NUR über ein Objekt arbeite.
        Diese Funktionen liefern dann immer gleich die ganze Tabelle mit all ihren Spalten, auch wenn ich z.B. nur nach drei bestimmten Kunden suche. Via PHP muss ich dann das mehrdimensionale Array durchsuchen...

        Mit einem Archiv könnte ich die Datenmenge vielleicht etwas verkleinern mit der PHP dann arbeiten muss...

        Wenn ich es also richtig verstanden habe, speichere ich also die Datenbank nach einem Jahr in einer extra Datenbank ab und mache für jedes Jahr eine eigene Tabelle (schmeiss da dann die Datenbank für das Jahr rein?) und kann die dann mit dem VIEW-Befehl bei Bedarf wieder zusammenfügen - falls ich mir z.B. die Arbeitszeiten eines Mitarbeites in den letzten 3 Jahren anzeigen lassen möchte...

        Kommentar


        • #5
          Zitat von Chili-Schaf Beitrag anzeigen
          Es werden viele Datensätze, da z.B. jeder Mitarbeiter täglich einträgt was er/sie wann, für welches Projekt, für welchen Kunden wie lange gemacht hat.
          Einfach um mal eine Hausnummer zu nennen. Wenn es ein aktueller Datenbank-Server ist und die Tabelle kleiner als 100.000 Datensätze ist, brauchst Du Dir vermutlich nicht zu viele Gedanken zu machen. Ausser diese Datenbankzugriffsschicht ist "strohdumm".

          Zitat von Chili-Schaf Beitrag anzeigen
          Wenn ich es also richtig verstanden habe, speichere ich also die Datenbank nach einem Jahr in einer extra Datenbank ab..
          Nochmal zur allgemeinen Definition:

          Eine Datenbank kann mehrere Tabellen enthalten, deshalb genügt eine Datenbank, die dann die verschiedenen Archiv-Tabellen pro Jahr enthält.

          Mit Hilfe der VIEW erscheinen diese Jahres-Tabellen wieder als eine gemeinsame große Tabelle.

          Grüße
          Thomas

          Kommentar


          • #6
            Bei 50 Mitarbeitern und täglich 2 Einträgen sind das 50 * 2 * 365 * 5 Einträge, also knapp 200.000 Einträge. Sehe da keine Probleme bezüglich Performance. Notfalls kannst du ja zwei Datenbanken verwenden, ein Archiv und ein Live-Stand. Monatlich schiebst du dann alle Einträge die älter als 2 Jahre sind ins Archiv. Wenn du in deiner Anwendung die Datenbankverbindung variabel und administrierbar hältst kannst du deine Anwendung zwischen Archiv und Live hin und herschalten. Evtl. noch ein globaler Flag (IS_ARCHIVE) und du sperrst das Archiv gegen Schreibzugriffe. Nur eine Idee, halte es aber für unnötig.

            Für das Prädikat sehr sehr viele Einträge musst du schon 2, 3 Nullen dranhängen.
            "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

            Kommentar

            Lädt...
            X