Discussion :

[zapkto]

Pourquoi n'avez-vous pas inclus l'orm de django dans vos tests ?

[imikado]

@zapkto je le répète ceci n'est pas un article benchmark, j'écrirais dès que possible un benchmark complet, parcontre je ne suis pas sur d'inclure django(python) ni ROR(ruby), ni hibernate(java) ni EntityFramework (.net) car je ne connais pas bien (pour ne pas dire du tout) ces langages

Après ce que je peux faire pour ce prochain article c'est ouvrir un topic pour demander aux developpeurs (vous) de me proposer les cas de benchmark manquant

[Aurélien LEQUOY]

ouai alors codé avec un ORM je ne vois pas comment cela peut etre plus rentable. Sachant que d'abord il faut former tout le monde ! Pour ma pars je fais beaucoup d'exotique et de query à la con alors le select simpliste est rarement ma tasse de thé. de plus faire des truc exotique avec un ORM ca demande une sérieuse d'apprentissage et c'est pas vraiment performant.

Après je ne vois pas comment du code ORM peut-être plus maintenant que du code SQL. sachant que le code SQL est quand même plus pérenne que du code ORM qui aura évolué entre les versions.

En principe c'est là qu'on me sors, oui mais tu peux changer de SGBD facilement !

Bin pour un client "grand compte" j'ai du passer de MySQL vers Oracle et cela à nécessité une semaine, certainement autant de temps que de refaire les quelques requêtes qui posaient problème... (c'était sous cakephp).

En parlant des perfs on oublie ...

Perso j'utilise juste une surcouche pour update / delete / insert (de faire en sorte que cela valide le modèle). plus une optionnel pour historiser les tables automatiquement si elles sont dans la liste des tables a historiser.