La question de la performance est vraiment mineure avec notre méthode actuelle d'abstraction à la base de données (c'est à dire de faire du SQL générique).
Cela ressemble à une abstraction mais c'est loin d'être optimal.
En revanche, si on avait choisi une méthode d'abstraction plus "complète" du type "mapping objet relationnel", ça oui c'est trop coûteux en performances. En tout cas avec les tests réalisés il y a quelques années.
Tu mélanges plusieurs choses. Ce n'est pas parce qu'on fait une abstraction de base de données qu'on est obligé de passer par la cas mapping relationnel objet. On peut très bien faire une abstraction de base de données et continuer à utiliser des tableaux contenant les données provenant de la base.
Sans la couche ORM, ce n'est pas tellement plus couteux et on gagne énormément en sécurité (injection sql,...) et en robustesse du code.
[^] # Re: Database
Posté par Nicolas (site web personnel) . En réponse à la dépêche Piwigo 2.3. Évalué à 3.
Cela ressemble à une abstraction mais c'est loin d'être optimal.
Tu mélanges plusieurs choses. Ce n'est pas parce qu'on fait une abstraction de base de données qu'on est obligé de passer par la cas mapping relationnel objet. On peut très bien faire une abstraction de base de données et continuer à utiliser des tableaux contenant les données provenant de la base.
Sans la couche ORM, ce n'est pas tellement plus couteux et on gagne énormément en sécurité (injection sql,...) et en robustesse du code.