Discussion :

[nigella]

Hello,

je souhaiterai faire cette requête à l'aide de Zend_Db_Select mais je ne sais pas comment sélectionner des champs en particulier, les multiplier et faire la somme du résultat.

Voici la requête en dur Sql que je souhaite traduire avec Zend_Db :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT SUM(price*quantity) AS total FROM `order_consumable_item` 
JOIN `informatique_consumable`
ON `order_consumable_item`.`consumable_id` = `informatique_consumable`.`id`
WHERE `order_consumable_item`.`order_id` = 70

Merci d'avance

[Njörd]

Bonjour,

Je t'invite à lire la doc qui est claire à ce sujet : Doc sur zend_db_select

Une fois que tu auras bien compris la syntaxe pour faire une jointure, une petite recherche sur le sum() en Zend et tu trouveras ton bonheur.

[CinePhil]

Puisque tu as su écrire la requête en SQL pur, ne t'embête pas à essayer de la traduire dans le dialecte Zend_Db. Envoie la directement via la méthode query.

Dès que la requête se complexifie un peu, le dialecte est encore plus compliqué que le vrai SQL alors ne pas s'embêter avec le dialecte ! Vive la V.O. !

[m4riachi]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$db->select()
->from('order_consumable_item', array('total' => new Zend_Db_Expr('SUM(price*quantity)'))
->join('informatique_consumable', '`order_consumable_item`.`consumable_id` = `informatique_consumable`.`id`', null)
->where('`order_consumable_item`.`order_id` = ?', 70);

[CinePhil]

C'est bien ce que je disais : bien plus compliqué qu'en SQL pur !
Avec en plus l'instanciation d'un objet Zend_Db_Epr qui prend du temps, de la mémoire... bref, moins performant !

[m4riachi]

Tout à fait d'accord avec vous CinePhil, mais sa question et d'avoir la requête en Zend_Db.
l’écriture de la requête en Zend_Db ça aidera les gens à savoir écrire avec Zend_Db.

[5h4rk]

Utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->query(...)

utilise également Zend_Db

[CinePhil]

Utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->query(...)

utilise également Zend_Db

Exactement !

Mon propos n'était pas de ne pas utiliser Zend_Db mais seulement de ne pas s'encombrer du dialecte propre à Zend_Db et autres saloperies d'ORM quand il est plus facile d'écrire la requête en SQL pur et de la soumettre tel quel via la méthode query au SGBD.

[5h4rk]

Tout à fait.

Ma réponse c'était pour le post juste au dessus du mien.

[eaglesnipe]

Bonsoir a tous,

Cela fait plusieurs fois que je lis, notamment de la part de CinePhil ) de ne pas s'embêter avec le dialecte Zend_Db a partir du moment où l'on sait écrire la requête SQL à mano. Je suis d'accord sur le principe. Néanmoins je me pose une question. Justement si ce dialecte Zend_Db existe, n'y a-t-il pas une raison à cela ?? Des traitements internes Zend qui ferait que c'est plus rapide ? Une sécurisation plus poussée ? Sinon quel serait l'intérêt de ce dialecte ??

J'avoue que me sentant à l'aise avec la syntaxe SQL pure et la syntaxe Zend_Db, je me pose souvent la question de savoir laquelle privilégier...

Par exemple un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->query('select * from user where user_name = ?', array($name));

Est-il plus ou moins performant ? Plus ou moins securisé ?

qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$db->select()
     ->from('user')
     ->where('user_name = ?', $name);

Merci d'avance.

[CinePhil]

Pour une requête aussi simple, ça doit être à peu près équivalent si on a l'habitude d'utiliser le dialecte.

Cependant, évitez de relancer la guerre des étoiles !

Ce qui sécurise, c'est de forcer le type de la variable au type de la colonne de la table pour éviter l'injection SQL.

Et dès que la requête se compelxifie un peu, le SQL est beaucoup plus simple et probablement plus performant car demandant moins de passage par du code Zend.

Pour le fun, voilà la dernière requête que j'ai eue à écrire hier soir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
SELECT m.id_message, m.date_creation, m.message, m.sharewith, m.nb_votes, 
	j.id_joueur, 
	j.nom AS nom_createur, 
	j.prenom AS prenom_createur, 
	j.photo AS photo_createur, 
	j.pseudo AS pseudo_createur, 
	COUNT(c.id_commentaire) AS nb_reponses, 
	CASE 
		WHEN vm.id_joueur IS NOT NULL THEN 1 
		ELSE 0 
	END AS vote_du_joueur 
FROM les_messages m 
INNER JOIN les_joueurs j ON j.id_joueur = m.id_createur 
LEFT OUTER JOIN les_commentaires c ON c.id_message = m.id_message 
LEFT OUTER JOIN votes_messages vm 
	ON vm.id_message = m.id_message 
	AND vm.id_joueur = ".$id_membre_connecte." 
WHERE m.id_joueur_mur = ".$id_joueur." 
GROUP BY m.id_message, m.date_creation, m.message, m.sharewith, m.nb_votes, 
j.nom, j.prenom, j.photo, j.pseudo, vote_du_joueur 
UNION
SELECT m2.id_message, m2.date_creation, m2.message, m2.sharewith, m2.nb_votes,
	j2.id_joueur, j2.nom, j2.prenom, j2.photo, j2.pseudo,
	COUNT(c2.id_commentaire) AS nb_reponses, 
	CASE 
		WHEN vm2.id_joueur IS NOT NULL THEN 1 
		ELSE 0 
	END AS vote_du_joueur 
FROM les_messages m2
INNER JOIN follow f ON f.flw_id_following = m2.id_createur
	INNER JOIN les_joueurs j2 ON j2.id_joueur = f.flw_id_following 
	LEFT OUTER JOIN les_commentaires c2 ON c2.id_message = m2.id_message 
LEFT OUTER JOIN votes_messages vm2 
	ON vm2.id_message = m2.id_message 
	AND vm2.id_joueur = ".$id_membre_connecte." 
WHERE m2.id_joueur_mur = f.flw_id_following
	AND f.flw_id_follower = ".$id_joueur."
GROUP BY m2.id_message, m2.date_creation, m2.message, m2.sharewith, m2.nb_votes, 
j2.nom, j2.prenom, j2.photo, j2.pseudo, vote_du_joueur 
ORDER BY date_creation DESC

Elle est facilement testable dans phpMyAdmin car il suffit de remplacer les variables par des valeurs existantes dans la BDD.
Si j'avais dû l'écrire en dialecte Zend_Db, j'y serais encore la semaine prochaine !

[eaglesnipe]

Merci pour cette réponse.

Il est vrai qu'une syntaxe SQL pure et bien plus compréhensible sur de grosses requêtes, je suis d'accord, et plus facilement testable.

Et pour le select *, ce n'était que pour l'exemple ! Je me résigne formellement à utiliser le sélecteur de champ générique dans mon code !

Merci bien !

[5h4rk]

Bonjour,
Alors pour te répondre.

Utiliser Zend_Db est plus lent, certe pas beaucoup mais un peu et cela dépend énormément de la requête.

Question sécurité c'est pour échapper les variables notamment éviter les injections SQL. De nos jours, tous les développeurs font leur propre système si ils n'utilisent pas un système comme Zend_Db.

Le grand point fort d'un tel système, c'est au niveau de la gestion des différents SGBD.
Il est possible de switcher aisément d'un SGBD à l'autre sans se soucier des quotes ou encore des syntaxe qui peut varier.
En générale par exemple, on ne redéveloppe jamais une application from scratch. On utilise un socle précédemment conçu et améliorer au fur et à mesure.

Pourtant d'une application à l'autre, le SGBD peut être différents (par exemple j'ai fais pour oracle, postgreSQL et MySQL).
Une couche d'abstraction trouve tout son sens à ce niveau.

Par ailleurs, cela peut également être utile pour les développeurs ne voulant pas s'embêter avec des requêtes en travaillant au niveau métier.

Par exemple avec Zend_Db, à partir d'une entité il est possible de récupérer les entité parentes ou enfantes très facilement. Ce qui imposerait une requête un peu plus compliqué.

Donc voilà pour moi, il faut faire la part des choses.

[eaglesnipe]

Merci pour tous ces éclaircissements.

L'idée est donc de trouver le meilleur compromis par rapport à l'envergure du projet et au contexte dans lequel il s'inscrit.

Merci bien !