Wie @eviltrout bereits erwähnt hat, setzen wir in einer Reihe von Plugins mittlerweile erfolgreich auf Migrationen und dedizierte Tabellen. Die Möglichkeit, Datenbank-Constraints durchzusetzen, hat die Leistung (Abfragen in beliebigen Spalten) und die Datenintegrität (durch eindeutige Indizes) verbessert. Diese beiden Aspekte haben sich insbesondere im Maßstab einiger unserer gehosteten Kunden als besonders wichtig erwiesen – etwas, das ich vor meinem Eintritt ins Team kaum bedacht hatte.
Das erste umfangreiche Plugin, an dem ich gearbeitet habe, war chat-integration, und ich habe dort eine sehr umständliche „fiktive ActiveRecord“-Lösung implementiert, die auf dem Plugin-Store aufbaut. Im Nachhinein wären dedizierte Tabellen eine weit bessere Wahl gewesen, und ich werde möglicherweise prüfen, das Plugin in Zukunft dorthin zu migrieren.
Dem stimme ich zu, wenn es um die Modifikation von Core-Tabellen geht. Das Hinzufügen oder Ändern von Spalten in bestehenden Tabellen kann später ungewollte Folgen haben und bleibt auch dann erhalten, wenn das Plugin deinstalliert wird. Davon rate ich dringend ab.
Dedizierte Tabellen sind hingegen mit relativ geringem Risiko verbunden. Wird das Plugin deinstalliert, bleiben sie einfach erhalten, ohne negative Nebeneffekte (sofern Sie keine Fremdschlüssel-Constraints einführen). Zurückgelassene Daten sind „nicht schlimmer“ als die Nutzung des Plugin-Stores.
Im Hinblick auf die Bereinigung könnten wir Rake-Tasks bereitstellen, die Plugin-Migrationen rückgängig machen. Aber ehrlich gesagt glaube ich nicht, dass dies häufig genutzt wird. Meine Annahme ist, dass Leute Plugins selten deinstallieren, und wenn doch, bevorzugen sie es, die Daten zu behalten, falls sie das Plugin später erneut installieren möchten.