Backup der ganzen DB-Daten

  • Hey,


    ich habe eine Datenbank mit mehreren Tabellen. Nun kann der Admin dort auch Datenbankeinträge in seinem Bereich löschen.

    Nun kann es vorkommen, das der Admin versehentlich viele Einträge löscht obwohl er es nicht wollte.


    Jetzt möchte ich dem Admin ne Funktion bieten welche wieder alles herstellt.


    Nun ist meine Frage wie sowas denn machbar ist?


    Meine Idee ist wie folgt:

    Ich erstelle noch eine weitere Spalte in jeder Datenbanktabelle. Der Standardwert ist 0. Nun wenn er löschen klickt wird dieser auf 1 gesetzt.

    Bei dem Selektieren der Daten aus der DB wird dann dieser Wert zur Abfrage verwendet.


    Auf Dauer wird es dann aber zu viel ?


    Habt ihr noch andere Vorschläge? Wie findet ihr meine Idee?


    Grüße,

    Stef

  • Hast Du richtig gedacht.

    Nennt sich Soft Delete.

    (google physical|hard deletion vs logical|soft deletion)


    Man müsste sich nur Dedanken machen, was man dann alles damit machen will.

    Musst Du zB irgendwann wissen, wann der Eintrag gelöscht wurde?


    Du kannst 2 Felder nutzen:

    SQL
    `is_deleted` TINYINT unsigned DEFAULT '0',
    `deleted_at` DATETIME DEFAULT NULL


    Oder nur das Feld `deleted_at`. Dann kannst Du beim SELECT angeben WHERE ... AND `deleted_at` = null;

  • Hey,


    okay. Danke der Info und vielen Dank . Wieder was dazu gelernt.


    Ich möchte damit lediglich nur alle gelöschten DB-Einträge mit dem aktuellen Datum wieder herstellen.


    Ich habe jetzt isDeleted und deletedAt als Spalte zu meinem beiden DB-Tabellen (termine, messages) hinzugefügt.

    Die Spalte isDeleted (INT) bekommt als Standard-Wert die 0. Wenn ein DB-Eintrag gelöscht wird wird dieser Wert auf 1 geupdated und in deletedAt wird das aktuelle Datum eingefügt. Bei der Überprüfung, welche gelöschten Einträge man wiederherstellen kann, prüfe ich auf das aktuelle Datum. Somit werden nur alle Einträge wiederhergestellt die am aktuellen Datum gelöscht wurden. Alle anderen werden nicht mehr wiederhergestellt. Sonst sind plötzlich gelöschte Nachrichten von vor über paar Monate noch dabei ;)


    Ich habe mal noch ne Frage.

    Ich habe zu aller erst für die Spalte deletedAt den Typ date genommen da dieser ja folgendes Format produziert : YYYY-MM-DD. Nun wenn ich als Default Current Timestamp hinzufüge kommt ein Error wegen falschem Default-Wert. Dann habe ich die gelassen. Habe dann einfach mal paar neue Einträge erstellt und musste sehen, dass in die Spalte deletedAt immer nur 0000-00-00 gespeichert wird. Habe daher die Spalte zum Typ Varchar geändert und das Datum dann von außen hinzugefügt.


    Warum wird in der Spalte deletedAt, Typ date, nicht das aktuelle Datum gespeichert sondern nur 0000-00-00?


    Gruß,

    Stef

  • Bitte kein VARCHAR für Datum.

    Und bevor ichs vergesse: isDeleted solltest Du vom Typ TINYINT setzen. Das spart Platz (nur 1 Byte statt 4 - siehe https://dev.mysql.com/doc/refman/5.7/en/integer-types.html).


    Wenn Du nur Jahr, Monat und Tag speichern willst, dann DATE.

    Wenn die Du die Zeit auch speichern willst, dann DATETIME.

    Wenn Du einen Zeitstempel speichern willst, dann TIMESTAMP.


    Unterschiede:

    DATE

    used for values with a date part but no time part.

    'YYYY-MM-DD' format

    range is '1000-01-01' to '9999-12-31'


    DATETIME

    used for values that contain both date and time parts.

    'YYYY-MM-DD HH:MM:SS' format

    range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'


    TIMESTAMP

    used for values that contain both date and time parts.

    'YYYY-MM-DD HH:MM:SS' format

    '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC


    INFO: nutze keinen TIMESTAMP wenn das Datum vor 1970 liegen kann. Im Zweifel immer DATETIME.

    EDIT: auch nicht, wenn zB ein Termin nach 2038-01-19 03:14:07 sein kann. Wenn das Tool|Website dann noch läuft, oder wir alle noch existieren :D


    Siehe: https://dev.mysql.com/doc/refman/5.7/en/datetime.html


    Und hier ist Dein Problem mit CURRENT TIMESTAMP - DATE akzeptiert keine Zeitangabe.

    Es hätte also zB "2018-04-18 12:00:00" in ein DATE Feld gespeichert werden sollen, dass nur "2018-04-18" aufnehmen kann.


    0000-00-00 wurde gespeichert, weil es keine DEFAULT value gab. Dann ist DATE "leer" 0000-00-00. DATETIME wäre "0000-00-00 00:00:00".

    Das sollte man aber vermeiden. Schon alleine weil es laut Docu nicht valid ist (siehe "range").


    Und Achtung: Du kannst auf das Feld deletedAt kein DEFAULT CURRENT TIMESTAMP setzen.

    Für den MySQL Server hieße das, dass bei einem neuen Datensatz (INSERT INTO) das Feld auf, naja, den momentanen Zeitstempel gesetzt wird.

    Alle neuen Datensätze wären also default (per Datum|Zeit) als gelöscht markiert.


    Setze deletedAt als DEFAULT NULL. Das heißt, dass es keinen Wert haben muss.

    Und NULL verschwendet keinen Platz.

  • Ok. Ich achte nie auf die Bytes. Sollte man auf die Bytes achten?


    Ja die Unterschiede habe ich mir auch angeschaut währenddessen. Habe Current Timestamp nur genommen, da trotz abspeichern des Datums von ausen, immernoch 0000-00-00 gespeichert wurde.


    Zitat

    0000-00-00 wurde gespeichert, weil es keine DEFAULT value gab. Dann ist DATE "leer" 0000-00-00. DATETIME wäre "0000-00-00 00:00:00".


    Okay. Wenn ich von ausen das Datum, im gleichen Format, in die DB-Tabelle eintragen lasse dann wird auch, wie bereits oben erwähnt, 0000-00-00 in dieSpalte createdAt gespeichert. Alles was ich versucht habe ging nicht. Selbst als ich dem Feld als Standardwert null gegeben habe. Da wurde nichts in die Spalte eingetragen.


    Darum habe ich auch als Notlösung Varchar genommen. Wenn ich weis warum typ date nicht geht dann ändere ich es natürlich.


    Warum ist das so?

  • Ich habe mir eben nochmals den Code angeschaut. Und siehe da, ich habe vergessen beim Update der Spalte die spalte createdAt zu updaten. Kein Wunder warum es nicht funktioniert.


    Danke für deine Mühe und gute Hilfe. :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!