Comme l’a dit @eviltrout, nous utilisons désormais des migrations et des tables dédiées dans plusieurs plugins, avec un grand succès. La possibilité d’imposer des contraintes de base de données a permis d’améliorer les performances (recherches dans n’importe quelle colonne) et l’intégrité des données (grâce aux index uniques). Ces deux aspects se sont révélés particulièrement importants à l’échelle de certains de nos clients hébergés – ce n’est pas vraiment quelque chose que j’avais envisagé avant de rejoindre l’équipe.
Le premier plugin substantiel sur lequel j’ai travaillé était chat-integration, et j’y ai implémenté un très fastidieux « faux activerecord », qui s’appuie sur le magasin de plugins. En y repensant, des tables dédiées auraient été un choix bien meilleur, et je pourrais envisager de migrer ce plugin vers cette approche à l’avenir.
Je serais d’accord, lorsqu’il s’agit de modifier les tables principales. Ajouter ou modifier des colonnes sur des tables existantes pourrait avoir des conséquences imprévues plus tard, et ces modifications subsisteront même si le plugin est désinstallé. Je déconseille vivement de le faire.
Les tables dédiées, en revanche, présentent un risque relativement faible. Si le plugin est désinstallé, elles resteront simplement en place, sans aucun effet secondaire négatif (à condition de ne pas introduire de contraintes de clé étrangère). Laisser des données en suspens n’est « pas pire » que d’utiliser le magasin de plugins.
En ce qui concerne le nettoyage, nous pourrions envisager de fournir des tâches rake qui « inversent » les migrations de plugins pour effectuer le nettoyage. Mais pour être honnête, je ne pense pas que cela sera beaucoup utilisé. Mon hypothèse est que les gens désinstallent rarement les plugins, et lorsqu’ils le font, ils préfèrent conserver les données au cas où ils souhaiteraient les réinstaller plus tard.