requete sql avec Zend_Db

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:

---

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

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.

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

Code:

---

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

---

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 !

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.

Utiliser

Code:

---

$db->query(...)

---

utilise également Zend_Db

Citation:

---

Envoyé par 5h4rk

Utiliser

Code:

---

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

Tout à fait.

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

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:

---

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

---

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

qu'un

Code:

---

1 2 3

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

---

Merci d'avance.

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 ! :P

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:

---

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 ! :roll:

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 !

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.

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 !