Avec tous les outils disponibles aujourd’hui pour simplifier le développement et rajouter des couches d’abstraction dans le but de faciliter le travail de maintenance, la sécurité et le développement, est-il encore pertinent de travailler avec du SQL en direct ?
Les ORM sont des interfaces qui viennent s’intercaler entre une base de données d’une part et un programme de haut-niveau (c’est à dire un programme final – pas forcément un programme de top qualité). En PHP, il y a par exemple Doctrine.
Les ORMs pointés du doigt
Les avantages des ORM sont de réduire la quantité de code à produire et d’avoir une certaine homogénéité (code objet). Malgré tout, on peut reprocher aux ORM :
- Une dépendance à l’ORM plutôt qu’au SGBDR sous-jacent (on remplace une dépendance par une autre) ;
- Des performances moyennes causées par l’ORM lui-même qui doit faire la « traduction » entre l’application et la base de données ;
- Un tuning clairement moins bon à cause des limitations de l’ORM qui n’a peut-être pas implémenté toutes les subtilités du SGBDR ;
- Des requêtes chaînées et des suppression en bloc qui sont parfois mal gérées ;
- Une difficulté générale de transcription entre les langages objets utilisés par les développeurs aujourd’hui et le fonctionnement relationnel des bases de données relationnelles : accès, héritage, polymorphisme, encapsulation…
- Des problèmes de types de données : comment faire correspondre des données proches mais avec de subtiles différences (les dates, les chaînes de caractères…) ;
- Des limitations avec les transactions : bien bordées dans les bases de données, les transactions sont un concept aux contours variables suivant les langages de programmation utilisés ;
- Des restrictions avec des logiques de bases de données que l’on ne retrouve pas en développement logiciel : le principe de l’intégrité référentielle par exemple.
SQL ou ORM : comment choisir ?
Le langage SQL pur est idéal lorsque :
- Il y a vraiment beaucoup de données à traiter ;
- La performance et la rapidité sont cruciaux ;
- Il y a des optimisations poussées à réaliser ;
- Il faut absolument respecter l’intégrité de la base (ACID) ;
- On veut savoir exactement ce qui se passe.
Passer par un ORM est parfait lorsque :
- On veut aller vite ;
- Il n’y aura jamais des volumes considérables à traiter ;
- Les données ne sont pas stratégiques (pas trop embêtant si il y a quelques pertes).