Quel choix pour de meilleures performances ?

[vince29]

Bonjour,

Voilà, je me pose la question suivante : quelle méthode de requêtage ou définition de modèle est la meilleur pour avoir de meilleure performance ?

J'explique un peu mon cas, actuellement, dans chaque model, je déclarais ma primaire de la façon suivante :

Code :

protected $_primary = 'id';

Et dans mon controller, pour obtenir mon résultat, je fais :

Code :

$row = $table->find($id);

Je dispose aussi de tables avec des clés primaires composées, j'ai vu que la même méthode pouvait être utilisée, mais une personne m'a fait la remarque qu'il est plus performance de ne pas déclarer les primaires dans les modèles, mais d'utiliser seulement les primaires au niveau SQL, c'est à dire qu'il me conseille de faire systématiquement des requêtes de la façon suivante :

Code :

1
2
3
4
5
$table= new Table();
		$data = $table->select()->setIntegrityCheck(false)
							->from('table')
							->where('id=1');
		$row = $table->fetchAll($data );

Pourriez-vous me donner votre avis svp ?

D'avance merci.

Vince

[ovh]

Je vais jeter un gros pavé dans la mare
Mon avis est qu'il faut privilégier avant tout un code lisible et orienté fonctionnel.
Je m'explique.

Si on choisit d'utiliser un framework et à fortiori un ORM (même si Zend_Db_Table n'en est pas vraiment un, mais il s'en rapproche), il faut oublier les performances brutes et les optimisations SQL, car ce n'est pas du tout l'objectif de ce genre d'outil...

Dans une approche classique ("à l'ancienne") on écrit des requêtes SQL pour chaque affichage, optimisées pour renvoyer uniquement les colonnes dont on a besoin, avec les jointures qui vont bien etc.

Mais rappelons qu'ORM signifie Object Relational Mapping ! Le but est de s'abstraire autant que possible de l'aspect persistance pour se concentrer sur le modèle objet au niveau fonctionnel. Les requêtes SQL sont générées automatiquement par l'ORM et sont relativement basiques. Là où on faisait une grosse requête spécifique, l'ORM fera des tas de petites requêtes simples et des boucles. C'est moins joli au niveau DB certes, mais c'est nettement plus propre au niveau code.

Il faut essayer de se détacher de la notion de base de données, et de raisonner uniquement en terme d'objets métier (héritage entre entités, composition, méthodes, responsabilités de chaque entité... bref les bonnes pratiques de conception objet). La persistance est gérée par les couches basses et on ne s'en préoccupe plus vraiment. A tel point qu'avec un bon ORM, on devrait pouvoir changer le moteur de persistance de manière radicale : au lieu d'être une DB relationnelle, on pourrait utiliser des fichiers XML, les modèles doivent pouvoir s'utiliser de la même manière.

Les développeurs ont souvent tendance à vouloir faire du code système (sql) à tout prix, alors qu'avec un ORM le but est de faire de l'objet

[Akta3d]

Je suis d'accord sur l'aspect qu'un framework est là pour nous simplifier la vie au niveau codage, la réutilisation de code, sa lisibilité et qu'il y aura forcément des pertes de performance puisque l'on essai de généraliser des concepts.

Mais le modèle objet permet également de spécifier les comportements souhaitez.

Pourquoi un framework ne pourrait pas faire les deux?



Ne pouvons nous pas surcharger la méthode find pour y coder ce que l'on souhaite?



J'ai souvent l'impression que l'utilisation d'un framework est souvent lié à la "simplification" de programmation et à la perte de performance. Je trouve cela dommage. Car je pense que l'on peux faire les deux.

[patbator]

Hello,

Je suis d'accord avec les 2 réponses précédentes
En utilisant un composant ZF normalement on accepte un compromis entre le temps de maintenance et la performance.
Tout framework ajoutera du code qui alourdi l'exécution.

Une fois que cela est dit, quand il y a un problème de performance, et uniquement à ce moment là, il faut profiler une exécution de l'application avec des données réelles et identifier les *vrais* goulets d'étranglements de ton appli. L'optimisation à priori est mauvaise car elle te prendra du temps pour des problèmes hypothétiques.

Si le goulet est une répétition de requêtes ou un type de requête venant d'un composant ZF, évidemment qu'il faut adapter le code, mais pas celui de ZF qui doit rester cohérent.
Il suffit de gérer le problème dans une couche à toi, en créant par exemple une méthode spécialisée dans un de tes objets.

À mon avis on peut dire que les problèmes de perfs apparaissent d'abord à des endroits imprévus et grossiers et qu'il vaut mieux investir du temps à coder les fonctionnalités de ton application puis tester sa montée en charge, la profiler et lever les plus gros lièvres à postériori.

@+

[ovh]

Totalement d'accord avec patbator

D'ailleurs, en général, les vrais problèmes de perf viennent d'un problème de conception dans la logique de tes objets métier, et plus rarement d'une requête SQL "non optimisée".

[vince29]

Bonjour à tous,
et merci pour vos réponses qui sont très constructives.

Au final, j'ai privilégié la déclaration des primaires dans mes modèles, quitte à utiliser un framework, autant l'utiliser jusqu'au bout ...

Encore merci.

Vince

[5h4rk]

Certaines personnes utilisent un framework pour se simplifier la vie sans avoir de reelles connaissances du langage ceux la sont voué à l echec tot ou tard. Mais pour les autres c est un gain de temps énorme et une reprise facile du code et ces derniers pour des soucis de performance seront agir en surchargeant en mettant en cache etc