problème de comptage.

par **cy4nur3** » 17 oct. 2007, 08:25

une solution pour faire la somme !!

SELECT menu_semain, SUM( 
     IF(menu_entree1 = '', 0, 1) 
   + IF(menu_entree2 = '', 0, 1) 
   + IF(menu_entree3 = '', 0, 1) 
   + IF(menu_entree4 = '', 0, 1) 
   + IF(menu_resistance1 = '', 0, 1) 
   + IF(menu_resistance2 = '', 0, 1) 
   + IF(menu_resistance3 = '', 0, 1) 
   + IF(menu_resistance4 = '', 0, 1) 
   + IF(menu_resistance5 = '', 0, 1) 
   + IF(menu_legume1 = '', 0, 1) 
   + IF(menu_legume2 = '', 0, 1) 
   + IF(menu_legume3 = '', 0, 1) 
   + IF(menu_fromage1 = '', 0, 1) 
   + IF(menu_fromage2 = '', 0, 1) 
   + IF(menu_fromage3 = '', 0, 1) 
   + IF(menu_dessert1 = '', 0, 1) 
   + IF(menu_dessert2 = '', 0, 1) 
   + IF(menu_dessert3 = '', 0, 1) 
) AS total 
FROM menu 
WHERE admin_id = 'kerlochj' 
GROUP BY menu_semaine

Merci a tous !!!

par **Hubert Roksor** » 16 oct. 2007, 14:38

Je vais faire court puisque le sujet ne reservira probablement pas : si chaque champs non-vide correspond à un plat et qu'il n'y a qu'un enregistrement par jour et par personne alors il suffit de lire tous les enregistrements, remplacer les champs vides par des 0, les champs non-vides par des 1 et faire le total de chaque ligne.

Code : Tout sélectionner

SELECT menu_jour, (
	  IF(menu_entree1 = '', 0, 1)
	+ IF(menu_entree2 = '', 0, 1)
	+ IF(menu_entree3 = '', 0, 1)
	+ IF(menu_entree4 = '', 0, 1)
	+ IF(menu_resistance1 = '', 0, 1)
	+ IF(menu_resistance2 = '', 0, 1)
	+ IF(menu_resistance3 = '', 0, 1)
	+ IF(menu_resistance4 = '', 0, 1)
	+ IF(menu_resistance5 = '', 0, 1)
	+ IF(menu_legume1 = '', 0, 1)
	+ IF(menu_legume2 = '', 0, 1)
	+ IF(menu_legume3 = '', 0, 1)
	+ IF(menu_fromage1 = '', 0, 1)
	+ IF(menu_fromage2 = '', 0, 1)
	+ IF(menu_fromage3 = '', 0, 1)
	+ IF(menu_dessert1 = '', 0, 1)
	+ IF(menu_dessert2 = '', 0, 1)
	+ IF(menu_dessert3 = '', 0, 1)
) AS total
FROM menu
WHERE admin_id = 'kerlochj'
  AND menu_semaine = 42

S'il peut y avoir plusieurs ligne pour le même utilisateur pour la même journée, alors il faut faire la somme de tous les totaux d'une journée. Donc la même chose, mais avec un SUM() autour des IF() et un GROUP BY menu_jour.

par **iclo** » 16 oct. 2007, 13:12

Je crois qu'on est tous d'accord que c'est cy4nur3 qui verra si il veut suivre les conseils qui lui ont été donné. Mon point de vue se base sur le fait qu'on a déja souvent vu des membres, qui bricolent sur une base de donnée bancales, et finissent par devoir tout démonter et reconstruire plus tard, en devant reprogrammé une grosse partie de leur script, voir même devant fermé temporairement leur site.
(Plus tard une erreur est détectée, plus "cher" elle coutera à corriger)

Concernant l'intégrité des données, tout à fait d'accord que les locks et transactions devront être envisagé selon les cas, mais la première étape est et restera le design de la base de donnée, sous forme de tables, suffisament normalisées. (Avant de construire une toiture étanche sur le chateau, on construit d'abord des fondations solides)

par **Tracker** » 16 oct. 2007, 12:27

En effet, c'est bien de promouvoir un schéma solide, mais pour les guerres d'idéologies il vous faudrait ouvrir un nouveau sujet.

Pour en revenir au problème,
j'aimerai avoir le nombre de plat que l'utilisateur "lamba" a pris pour une semaine donnée.
Ce que je ne comprends pas c'est que d'après le schéma je ne vois ni l'identité de l'utilisateur ni les quantités de chaque plat. Comment conserves-tu ces informations ?

Voilà ce que j'ai compris:

Code : Tout sélectionner

identité: 
  admin_id
quantités de chaque plat: 
  c'est toujours 1, vue qu'un enregistrement correspond à la saisie des plats d'une journée par individu. 
  le nb de plats par jour/admin_id est le nombre de champs (entree...dessert) ne contenant pas ''

Le schema est, en effet bancal, et le revoir à la fin du dev ??

Celui qui connait tout. (encore un nouveau pseudo)

par **Hubert Roksor** » 16 oct. 2007, 12:18

En effet, c'est bien de promouvoir un schéma solide, mais pour les guerres d'idéologies il vous faudrait ouvrir un nouveau sujet.

Pour en revenir au problème,

j'aimerai avoir le nombre de plat que l'utilisateur "lamba" a pris pour une semaine donnée.

Ce que je ne comprends pas c'est que d'après le schéma je ne vois pas l'identité de l'utilisateur, et je ne suis pas sûr de comprendre comment tu conserves les quantités de chaque plat. Explications please ?

par **zeus** » 16 oct. 2007, 12:13

Dans un cadre non professionnel, le membre sera libre arbitre de vouloir apprendre ou non.
Dans un cadre professionnel, le membre devra faire avec sa hiérarchie et le temps qui est disponible.

Cela n'a rien à voir avec l'utilité ou non de donner des conseils. Si cy4nur3 n'a que faire des conseils, c'est son choix.
En attendant, c'est pas parce que tu avances qu'il ne faut pas le conseiller qu'on ne le fera pas.

Concernant le passage "depuis bien avant toi", c'était justement pour te faire comprendre que tu n'es pas le 1er à penser tout savoir. Moi pour le 1er, j'en apprend tout les jours ici et je suis bien content de me remettre en question quand j'ai un avis contraire qu'il m'aide à affiner mon esprit critique.
Dans ce post, c'est différent, parce que ce n'est pas constructif.

En attendant, vu qu'on est completement HS, je t'invite à continuer cette discussion en PM et pas ici, sachant que cy4nur3 attend peut être toujours une aide.

par **Tracker** » 16 oct. 2007, 11:54

Ce qui m'agace dans ta remarque, c'est que, si je te comprend bien, soit on maitrise tout, soit ça ne sert à rien de penser design de base puisqu'on ne maitrise pas tout.

C'est une règle que nous suivons ici depuis bien avant toi, nous donnons des pistes d'amélioration, si le membre est tenté, il les applique et s'il est bien chaud, on l'invite à aller voir plus loin.

Maintenant, il faut bien commencer par quelque part et je trouve que refaire le schéma de la base me semble être un bon point de départ

Pour un projet perso, une initiation, ou tous autres buts non professionnels visant à l'apprentissage, cette façon d'opérer est pertinente et necéssaire, mais je ne suis pas sûr que cy4nur3 soit dans ce cas.
Par contre l'objectif pour un dev pro est effectivement de tout maitriser, sans quoi l'intérêt de passer par un sous-traitant, ou un freelance, ou un salarié devient plus que douteux voir mal-honnête, l'utilisateur finale devant s'appuyer aveuglément sur le système, mais là le peut-il ?

Je passe sur le passage "[...] depuis bien avant toi [...]", je ne pense pas forcement que la pertinence d'une remarque dépende de la date d'inscription de l'intervenant.

Tracker.

par **zeus** » 16 oct. 2007, 11:23

Ce qui m'agace dans ta remarque, c'est que, si je te comprend bien, soit on maitrise tout, soit ça ne sert à rien de penser design de base puisqu'on ne maitrise pas tout.

C'est une règle que nous suivons ici depuis bien avant toi, nous donnons des pistes d'amélioration, si le membre est tenté, il les applique et s'il est bien chaud, on l'invite à aller voir plus loin.

Maintenant, il faut bien commencer par quelque part et je trouve que refaire le schéma de la base me semble être un bon point de départ

par **Tracker** » 16 oct. 2007, 10:38

Alors un problème de design, de plus ou de moins, me parrait bien accessoire...
C'est une question de point de vue, mais, si un jour, cy4nur3 devra ajouter une fonctionnalité supplémentaire à son système de cantine, et qu'il se rendra compte que c'est impossible sans tout recommencer, ou bien que ses scripts prennent un temps démesuré pour s'exécuter, ce ne sera peut-être pas tellement un détail.
Désolé, mais pour moi, concevoir des scripts sur une base de donnée boiteuse, c'est comme construire un chateau sur un marécage, on finit tôt au tard par patauger...

Je suis d'accord avec toi, alors t'aggace pas

, je dis juste qu'une base bien designée, remplie de valeurs débiles, c'est pas mieux non plus...

ps: Je dois avouer que j'ai du mal à comprendre ce que les transactions et les locks viennent faire dans le design de base d'une base de donnée

Je dis simplement que le design ne fait pas tout, pour garantir l'intégrité des infos il faut obligatoirement comprendre et gérer les problématiques de lock et de transaction, sans lesquelles tu pourris au runtime progressivement tout... Et le problème est le même quelque soit le language, php ne déroge pas à la règle.

Tracker.

par **cy4nur3** » 16 oct. 2007, 10:38

n'importe koi maintenant ! !lorsque j'execute ta requete il me met impossible d'afficher la page ...

par **zeus** » 16 oct. 2007, 10:32

Effectivement, on peut se permettre de donner son avis sur la modélisation de la base qui est, comme l'a dit iclo, LE socle de l'application plutôt que de donner des solutions que nous savons forcément branlante.

Maintenant, on peut effectivement parler modélisation sur MySQL 4.1 sans rentrer dans le SQL avancé

par **iclo** » 16 oct. 2007, 10:28

Alors un problème de design, de plus ou de moins, me parrait bien accessoire...

C'est une question de point de vue, mais, si un jour, cy4nur3 devra ajouter une fonctionnalité supplémentaire à son système de cantine, et qu'il se rendra compte que c'est impossible sans tout recommencer, ou bien que ses scripts prennent un temps démesuré pour s'exécuter, ce ne sera peut-être pas tellement un détail.
Désolé, mais pour moi, concevoir des scripts sur une base de donnée boiteuse, c'est comme construire un chateau sur un marécage, on finit tôt au tard par patauger...

ps: Je dois avouer que j'ai du mal à comprendre ce que les transactions et les locks viennent faire dans le design de base d'une base de donnée

par **Tracker** » 16 oct. 2007, 10:19

vous n'avez pas de solution a me proposer?

Le requête que je t'ai posté tourne chez moi avec tes infos sur mon serveur MySQL 5. Donc soit essaie de le faire fonctionner chez toi (au pire en changeant de serveur), soit revois complètement ton schema d'info, mais en débutant tu risques de tomber sur un modèle aussi bancal que le premier.

A toi de voir.

par **cy4nur3** » 16 oct. 2007, 10:15

vous n'avez pas de solution a me proposer?

par **Tracker** » 16 oct. 2007, 10:11

C'est toi qui voit, et tant mieux si ça fonctionne comme ça.

Mais saches qu'en plus de faire pédaler inutilement le serveur de base de donnée, tu as le risque que si un jour on te demande d'ajouter des fonctionnalités sur l'application, tu risques de te retrouver dans une impasse, avec une base de donnée difficilement modifiable, puisque remplie de donnée.
Alors que sur une structure normalisée, la plus part du temps, un ajout de fonctionnalité se fait sans devoir tout redémonter.

Bonne continuation...

Je suis d'accord avec toi, le design est fondamental. Mais gérer des informations n'est pas à la portée de tout le monde, une structure fiable c'est une chose encore que c'est inaccessible avec un modèle de table MyIsam (pas d'intégrité...), mais l'exploiter logiciellement de façon correcte c'est une autre histoire. Dès lors qu'on ne gère ni lock, ni transaction, on fait forcement n'importe quoi, à croire d'ailleurs que ces principes n'existent pas vue le contenu de quasiment tous les messages postés.

Alors un problème de design, de plus ou de moins, me parrait bien accessoire...

Tracker.

problème de comptage.

Répondre

Étendre la vue Revue du sujet : problème de comptage.

Re: problème de comptage.

Re: problème de comptage.