Bonjour à tous,
Je découvre ROR depuis quelques jours, et je m’intéresse à l’abstraction de base de données.
Remarque : J’ai déjà utilisé des frameworks MVC tels que ZF ou Codeignitor.
J’ai vu le concept de « migration ». Je me demande si c’est bien utile.
Je lis que les migrations sont utiles pour garder une trace des modifications apportées au schéma de la base. OK, mais :
Je lis que les migrations sont utilisées pour garder une trace des modifications apportées au contenu de la base. OK, mais :Si vous voulez garder une trace de toutes les modifications apportées sur le schéma d’une base, pourquoi ne pas conserver ce schéma dans un outil de gestion de version, tout simplement ? (Exemples : Git, SVN ou autre).
D’autre part, en ce qui concerne l’interface de sélection, je constate qu’elle est très similaire à celle de ZF.Vous ne devriez pas modifier la base directement en production. Et si vous êtes amené à le faire, vous devriez faire une sauvegarde de cette dernière avant... on ne sait jamais. D’ailleurs, si vous utilisez les migrations, il serait bon de mes tester avant ! Et puis, tout changement n’est pas réversible ! La sauvegarde est, dans tous les cas, indispensable.
Et mon expérience de ZF m’a appris cela :
Quand vous développez une grosse application, vous devez écrire de grosses requêtes avec des jointures de différents types, en utilisant des fonctions SQL...
Dans ces conditions la couche d’abstraction devient un énorme boulet.
- Vous devez bien connaître le schéma de votre base pour l’utiliser efficacement.
- Vous devez bien connaître, dans les plus petits détails, les subtilités (très mal documentées) de la couche d’abstraction.
Vous vous retrouvez à écrire de longues suites d’appels de méthodes avec des options...
Et vous vous dites :
On va vous dire :C’est illisible ! Une simple requête SQL bien présentée (indentation, commentaires...) est 100 fois plus lisible !
Oui, mais... avez-vous déjà changé de base de données ?Oui, mais, si un jour tu veux passer de MySql à Oracle, tu peux le faire sans changer une ligne de code !
Et si vous le faites, ce ne sera pas avant 3 ou 4 ans... D’ici là, votre framework aura évolué... Et vous serez obligé de modifier le code.
Et puis on ne change pas de base pour le plaisir. En général, un tel changement est motivé par un problème de fond. Ce changement s’accompagne d’autres changements...
Je me pose la question de l’intérêt d’utiliser Active Record pour les gros projets.
Quel retour d’expérience avez-vous ?
Utilisez-vous toute l’artillerie Rails ? (les migrations...).
Est-il possible de se passer d’Acive Record ?
Merci,
Denis
Partager