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

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é

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

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.

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

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.

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.

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 ?

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: Le schema est, en effet bancal, et le revoir à la fin du dev ??


Celui qui connait tout. (encore un nouveau pseudo)

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)

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

une solution pour faire la somme !!
Merci a tous !!!