Neuste MySQL-Einträge tabellenübergreifend filtern

[Loesch-Knecht]

Liebes Forum,

bitte hilf !

Das Problem:

Ab und zu installierte ich in meinem Wordpress testweise neue Plugins. Um diese bei Nichtgefallen wieder zu löschen, reicht es leider oft nicht aus, sie im WP-Backend zu löschen, denn oft werden durch die Plugin-Installation Tabellen angelegt oder Einträge in bestehende Tabellen gemacht, die bei der herkömmlichen Deinstallation leider verbleiben und die Datenbank zumüllen. Also sollen diese Restbestände in der MySQL-DB gelöscht werden. Nur: Wie finde ich diesen "Restmüll"? Oftmals lassen die Einträge keinen Rückschluss auf den Verursacher (das eigentlich schon gelöschte Plugin) zu.

Die (Schein-?) Lösung:

Wenn man das Ganze zeitnah (nach (De-)Installation) erledigen will, wäre theoretisch das Problem lösbar durch eine SQL-Abfrage, die a) die neusten Tabellen und b) Einträge in bestehende Tabellen in der gesamten Datenbank, also tabellenübergreifend auflistet. Mir sind Abfragemethoden innerhalb einer Tabelle bekannt, aber geht das auch tabellenübergreifend? Und wenn ja: Mit welcher Abfrage? Evtl. scheitert mein Ansatz daran, dass die Tabellen offenbar kein gemeinsames Feld haben, das (als gemeinsames Kriterium) das Datum der Anlage des Eintrags ausweist – vielleicht taucht das aber auch nur in den Tabellen nicht öffentlich auf und ist irgendwo versteckt?

Danke für eure Hilfe.

PS: Die dem einen oder oder anderen vielleicht in diesem Zusammenhang kommende Idee "Sandbox" scheint nicht wirklich eine Alternative zu sein, denn oftmals muss erst nach Jahren ein Plugin ausgetauscht werden ...

[lstegelitz]

Ich glaube nicht, das es möglich ist festzustellen (per Query), welche Veränderungen es an Struktur oder Daten gegeben hat.. du müsstest im Vorfeld in Erfahrung bringen, was geändert wird. Ein "Vorher/Nachher" Abbild der DB Struktur ist, je nach Umfang, sehr sehr aufwendig. Je nach Software gibt es etwas wie eine Migration, die die Änderungen vornimmt - in dem Fall musst du untersuchen, was diese Migration verändert und es "umdrehen".

• Erzeugte Tabellen (CREATE TABLE) sind noch einfach (DROP TABLE)
• Erzeugte Felder in Tabellen (ALTER TABLE .. DROP COLUMN)
• Eingefügte Datensätze - u.U. schwer erkennbar, wenn Daten nicht per INSERT INTO eingefügt worden sind

IMHO gibt es hier keine simple/einfache Lösung.
Die "sicherste" Lösung wäre ein Voll-Backup der Datenbank vor der Installation des Plugins. Beim Einspielen des Backups gehen aber alle Daten verloren, die später hinzugekommen sind, dh. die Evaluation des Plugins kann nicht ewig dauern.

[hellbringer]

Backup machen, Plugin installieren und ausprobieren, Backup wieder einspielen.

[MichaelKre]

Oder um sich das Hin und Her zu sparen. Nur mit einer DB-Kopie testen und erst bei gefallen das Plugin auf die Livedaten loslassen.

[Loesch-Knecht]

@lstegelitz : Danke!

@hellbringer: Trifft es nicht: Erstens kann ich damit nur testen, ob das Plugin meinen Vorstellungen entspricht oder nicht, sehe aber nicht, welche Spuren es in der Datenbank hinterlässt, und auf eben diese zielte meine Frage ja ab. Zweitens lässt du den Zeitfaktor ("oftmals muss erst nach Jahren ein Plugin ausgetauscht werden") außer Acht: Will man nach Jahren ein bislang genutztes Plugin einschließlich sämtlicher Spuren loswerden und ersetzt deshalb die aktuelle Datenbank durch eine vor Installation des Plugins erstellte, ist man zwar das Plugin los - aber eben auch alles andere, was seit diesem Zeitpunkt in die Datenbank geschrieben wurde. Mein Tipp: Nicht aus der Hüfte schießen, sondern erstmal denken. (Sorry, aber wenn das eine Antwort eines Newbies gewesen wäre, hätte ich ja die Klappe gehalten, aber als Moderator einen solchen Unsinn zu raten, ist entweder überheblich oder dumm.)

[hellbringer]

Naja, mit aus der Hüfte schießen und nicht nachdenken kennst du dich ja aus. Denn woher weißt du, dass die neuesten Einträge einer Tabelle von einem bestimmten Plugin stammen? Das kann ja alles mögliche sein. Ich denke, du willst das Problem auf der falschen Ebene lösen.

Ich bleibe bei meiner Antwort. Backup machen, dann halt später noch ein Backup machen und das Diff davon anschauen, dann siehst du was sich geändert hat. Das bringt natürlich nur was, wenn man das zeitnah macht. Irgendwas nach Jahren rückverfolgen zu können ist praktisch unmöglich, das kannst du dir abschminken.

Oder du schaust dir den Source Code des Plugins an, wo was in die Datenbank geschrieben wird. Das ist natürlich immer eine Möglichkeit.

[Loesch-Knecht]

@ heilbringer: Auch dir danke! Ich weiß zwar noch nicht, was ein "Diff" ist, aber das ist ein Ansatz, den ich ergoogelnd weiterverfolgen werde.

[reddighamburg]

Diff ist ursprünglich ein Linux Befehl, der die Unterschiede zwischen zwei Dateien zeigen kann, wird aber inzwischen allgemein für die strukturierte Darstellung der Unterschiede zwischen zwei gleichartigen Datenspeichern verwendet.
Was er meint ist, du sollst ein Programm zur Hilfe nehmen, was dir genau die Unterschiede zwischen deinem Vorher- und Nachher-Backup anzeigen kann.
Wenn du zweimal mit den selben Einstellungen einen Dump der DB machst, erhältst du effektiv zwei sehr ähnliche Textdateien, die sich leicht vergleichen lassen.
Tools, die das können, gibt es viele.