voila, j'ai une table... avec 4 niveaux de prix en fonction de la quantité, en resumé...ça donne ça :
 
bo_numint1, bo_numint2, bo_numint3, bo_numint4, bo_numdbl1, bo_numdbl2, bo_numdbl3, bo_numdbl4
 
pour exemple :
pour les quantités j'ai :
bo_numint2=1
bo_numint3=4
bo_numint4=7
bo_numint5=10
 
pour les prix j'ai :
bo_numdbl1=5.5
bo_numdbl2=5.0
bo_numdbl3=4.7
bo_numdbl4=4.3
 
... il va de soit que tout ça est sur la même ligne de la même table donc pas de liaison ou autre
 
dans ce cas là on est bien d'accord que si je choisi si je choisis 1 exemplaire de mon produit il va me couter 5.5€, si j'en prend 5 il va me couter 5.0€ et si j'en prends 8 il va me couter 4.7€ piece.
 
 
l'autre chose à savoir c'est qu'il peut ne pas y avoir forcement 4 niveaux de degressif... par exemple il peut ne pas y en avoir du tout même ! dans ce cas ça donne ça :
 
pour les quantités :
bo_numint2=1
bo_numint3=
bo_numint4=
bo_numint5=
 
pour les prix :
bo_numdbl1=5.5
bo_numdbl2=
bo_numdbl3=
bo_numdbl4=
 
dans ce cas là si je prends 1 exemplaire ou 2, ou 6 ou 100 ou 1000 il me coutera toujours 5.5€
 
 
... jusque là tout va bien !
 
 
la question est surtout :
en PHP... Quelle condition je vais ecrire pour qu'il me prenne toujours la bonne valeur ?
 
ce que j'ai fait :
 

 
ma fonction fonctionne presque bien.. sauf que quand j'ai des champs vides dans ma table.. et bien il ne trouve pas mon prix !

euh question bête, tu n'as pas essayé de ne sélectionner de base que le bon prix en sql?

pour ça faudrait déjà qu'il n'ait pas un modèle des données conçu par un mongolien...

A mon avis ça aurait été bien plus simple avec une liaison sur une autre table pour gérer les prix par rapport aux quantités. Parce que dans ce cas là tu n'aurais qu'à récupérer le prix pour la quantité max dans celle qui sont inférieur à ta quantité choisie. Et en plus tu ne te retrouverais pas avec des champs vides!

J'ai fait que survoler le post...

d'où mon histoire du 8° jour

une fois de plus on tourne autour du pot... ce modele de données ce n'est pas moi qui l'ai conçut... donc ! je me plie aux règles et je cherche des solutions pour faire de sortes à ce que tout fonctionne ! j'ai qu'une seule et unique table pour toutes les informations concernant les produits... je n'ai aps le droit de changer le modele... donc je dois faire avec !

t'a qu'à faire une vue  
 
 
sinon ben t'as pas 36 solutions.
 
tu récupères tes 4 champs de quantité. quand t'as trouvé une quantité strictement suppérieure, tu vas lire à reculon tes 4 champs de prix à partir de index - 1 que t'as trouvé dans ton premier test. et tu te contentes as de retourner le premier, mais quand t'en à un.
 
Par exemple...

 

 
Franchement, on tourne pas autour du pot.
L'algo est évident. Si tu pars d'un modèle aussi POURRI (ça mérite la prison que de pondre des merdes pareilles) je vois pas ce que tu viens nous casser le cul à demander un truc "le meilleur possible".

(chais pas ce que j'ai aujourd'hui, chuis de mauvais poil. groumpf, vivement demain)

bah justement si je vous demande un conseil, c'est parceque c'est pas un algo habituel... celui que j'ai fait ne fonctionne pas... alors je demande si vous avez mieux à me proposer... je demande pas de critiquer les tables que je n'ai même pas conçu mais de m'aider justement à les faire fonctionner !

mets tous tes couples (prix, nb article) dans un tableau, et parcours-le...il n'y a pas vraiment de difficulté, là...

j'y avais pensé aussi... ya une fonction array pour comparer tout ça ? qui va me trouver la clé la plus proche de ma valeur ?

tu veux pas 100 balles et un mars, aussi?

ouai je veux bien mais là je suis à la diet !
 
... non mais je suppose qu'en combinant les fonctions array... je pourrai m'en sortir

t'as regardé le code que j'ai écrit hein ?
dit-moi ?
 
je fais pas de php, et pourtant j'ai résolu ton problème. à priori, ça doit même marcher tel quel si tu récupères les infos de la base façon "old school".

A ta place moi je changerais ça dans la bdd, en plus ça peut se faire rapidement en créant une nouvelle table puis un INSERT à partir d'un SELECT.

s'il l'a pas créée lui-même c'est qu'il y a p-e déjà une appli qui l'utilise...

d'où l'intérêt de faire une vue.
 
quand je vous dit que c'est utile de faire des vues
 
moi y'a des fois, je me dis que je prêche dans le désert

Moi j'ai rien dit, pour la vue.

Oui c'est vrai la vue ici irait bien.
Mais bon...

la vue elle est vite fait...
 
j'ai une table...
 
un champ id
20 champ varchar 255
5 champs int
10 champs double
1 champ date d'activation
1 champ date de peremption
1 champ date de creation
1 champ id de recipient
1 champ de relation de recipient
 
donc.. en quelques mots.. pour creer une fiche produit je dois me servir de tout ça !  
(et encore je l'ai fait evoluer parcequ'au debut j'avais que 2 champ int et 2 champs double ! mais le probleme c'est que ce n'est plus du tout compatible avec les anciennes versions)
 
 
PS : effectivement je suis dépendant d'un application de type CMS toute faite par la boite dans laquelle je bosse.. donc j'ai pas le droit de faire ce que je veux !

ben elle est pas compliquée à écrire la vue hein...
 

 
ensuite pour retrouver le prix du produit d'id "25" ayant et la quantité "50" c'est pas plus compliqué que ça :
 

deux semaines plus tard.. je retourne sur mon projet... ma solution est donc la suivante :
 

 
me reste un détail à corriger... comment faire quand un de mes $row_tab['bo_numintx'] est vide ?
 
en résumé... il fallait bien aller à reculon... chose qui ne m'etait pas évidente jusqu'à present ! maintenant ça a l'air de fonctionner

voila ! ça ça marche !
 

proprement avec la vue que je t'ai filé.
et tes profs sont bons à piquer, tu peux leur transmètre le message.

 
je ne peux pas imbriquer les requetes SQL (la version de MySQL qu'on utilise ne le gere pas) de plus je cherchais un moyen simple... une condition bien écrite me parait suffisante ! mais j'arrivais pas l'ecrire (vu comment la table est renseignée).. maintenant avec mon switch ça marche... et je ne pense pas que ce soit moins propre qu'une successions de requetes SQL

une vue, c'est pas une succession de requêtes hein...
 
une vue c'est une abstraction du modèle afin d'obtenir une entité métier qui répond exactement à la structure dont tu as besoin pour faire des traîtements, c'est pas du tout la même chose.
 
anyway, si ta version de mysql supporte pas, c'est mort. pour des fins éducations, on doit plutôt utiliser PostGreSQL (success d'Open Ingres, SGBD sur lequel j'ai appris), qui a l'avantage de couvrir toute la norme SQL 92 (et du coup ont sait ce qu'on peut faire proprement, plutôt que d'inventer des tecniques dégueux à cause de limitations éphèmères d'un SGBD qui n'est pas terminé).
 
ça confirme d'autant plus à quel point tes profs sont nuls. c'est quoi comme école qu'on sâche qu'il ne faut pas la faire ?

 
 
.. euh.. là il y a un mal entendu... je sais que dès fois je me comporte comme un débutant... mais je ne suis pas dans une école !      

ah, tu parlais de projet, spoursa.
mais à la base, c'est vrai que quand on bosse on peut faire aussi des projets je fais de la TMA depuis trop longtemps moi

oui je suis bel et bien en poste actuellement... mais je suis un autodidacte à la base... donc j'ai pas toutes les connaissances théoriques qui ne m'handicapent pas vraiment mais qui peut etre pourraient m'aider parfois... jusqu'à présent j'arrive à me débrouiller.. j'ai tout de mêmes quelques bases (Modèlisation et normalisation de données (Merise) UML etc etc...) je sais me debrouiller.. mais je ne les utilise que pour des trucs complexes (une boutique en ligne par exemple.. là on a pas le droit à l'erreur !) ... mais là le probleme est plus grand que ça... vu que le modèle de données est deja écrit.. et qu'il doit etre adapté sans etre modifié en fonction de chaque besoin

Par curiosité, aurions nous le loisir de comprendre pourquoi le mcd qui a manifestement été puni de toute logique, n'est pas modifiable
 
Parce que je fais que répéter une fois de plus là, mais c'est horrible comme modèle et tes galères n'en sont qu'à leur début

ça n'est pas modifiable, ou pas facilement, dans le cas où on a déjà toute une application/un site qui tourne avec un modèle.

enfin qui "tourne"... c'est un bien grand mot. J'aurais plutot dit "qui n'est pas encore tomber en panne, par on ne sait quel mystere"

C'est vrai qu'un modèle mal conçut ça laisse supposer tout un tas d'autres problèmes.

des fois ca coute moins cher de tout remettre a plat que de continuer a vivoter avec un vieux machin qui marche par on ne sait quel miracle...

par chez nous, on dit "elle est tombée en marche" dans ces cas là

oui, on dit ca aussi par chez nous

 
et bien tout simplement parcequ'il s'agit d'un "outil" qui n'etait pas destiné au depart à faire ce genre d'application...  et aussi parcequ'il s'agit d'un "socle" qui est utilisé depuis des années sur des centaines de sites.. et qu'il faut garder un minimum de compatibilité avec les autres outils... le MCD du CMS complet est deja très complexe ! car là il ne s'agit que d'un petit outil qui sera géré par le site tout entier !