requête SQL exigeante

Qui utilise encore du SQL pur ?

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).