Bonjour
j'essaie de construire une requete avec $q=$this-createQuery(t)
et $q-select(...)
et dans ce select, deux champs calculés, aliasés avec AS
exemple: SUM(c.montantNeg)+SUM(c.montantPos) AS somme_ech
j'arrive dans les actions et les vues a utiliser mon champs somme_ech
avec getSommeEch()
Le 03/08/2011 16:28, g...@vandencruche.fr a écrit :
Dèjà il est dangereux de mettre des requetes en dur dans symfony,
Doctrine est assez puissant pour gérer la requete
Bonjour
Effectivement
Alors comment gérer en doctrine un champs calculé utilisable dans une
clause having et dans les vues ?
Ce n'est pas ce que j'ai voulu dire, Symfony et Doctrine n'egaleront jamais un
langage comme PLSQL par exemple
Il faut donc peut etre analyser autrement la requête ?
Pourquoi cumuler et regrouper dans la requete ?
Le 3 août 2011 à 14:40, LeDabe goo...@ledabe.net a écrit :
Le
Le 03/08/2011 16:51, g...@vandencruche.fr a écrit :
Pourquoi cumuler et regrouper dans la requete ?
En fait, je préfèrais que les données qui arrivent soient un maximum
regroupées et traitées
pour limiter le traitement en PHP, et pensant que les traitements MySql
sont peu etre plus performants
Le 03/08/2011 17:19, g...@vandencruche.fr a écrit :
Le volume de données est il important ?
il y a une table principale qui peu aller de 10 a quelques centaines de
lignes
jointe a une table secondaire qui rajoute quelques lignes par
enregistrements (que je totalise justement)
voici ma requete a
1000 enregistrements maxi ? c'est rien du tout
Je te conseilles de minimiser les requetes, le temps que tu va perdre sous php
sera largement recupéré par la requete simplifié
Le 3 août 2011 à 15:32, LeDabe goo...@ledabe.net a écrit :
Le 03/08/2011 17:19, g...@vandencruche.fr a écrit :
Le
D'accord
Je vais donc abandonner le HAVING en SQL
mais je préfère garder mon 1er SUM, sinon j'aurais trop de données
superflues récupérées.
Je vais faire des essais et vous tient au courant
Merci
Le 03/08/2011 17:43, g...@vandencruche.fr a écrit :
1000 enregistrements maxi ? c'est rien du
