Compter le nombre de possibilité

moijhd · 14-03-2010 15:17:56

Bonjour,

J'ai trois tables : produits (id1), matieres (id2, stock),

composantes (id1, id2, quantite).

Les matières étant affectées d'un stock, je veux savoir

combien de produits je peux former.

Exemple :

Produit : Hot dog

Composantes (format : élément, quantité nécessaire) :
- Baguette, 0.25
- Ketchup, 0.05
- Saucisse, 1

Matières (format : élément, quantité en stock) :
- Baguette, 10
- Ketchup, 1
- Saucisse, 15

Je peux former 15 Hot dog, le facteur limitant étant les saucisses.

Je sais résoudre le problème en utilisant plusieurs requètes, mais mon je voudrais n'avoir qu'une seule requète Et je ne connais pas bien les fonctions SQL...

La requète qui me permet de retrouver les matières associées à un produit :

[code php]
<?php
$Sql = '
SELECT
la_quantité_maximale
FROM
produits,
INNER JOIN
composantes
ON
composantes.id1 = matieres.id
WHERE
composantes.id1= '.$IdProduitVente.'
';
?>
[/code]
Merci.

Dernière modification par moijhd (14-03-2010 15:25:22)

Jc · 28-04-2010 09:41:20

Bonjour,

Il est possible de créer une requête qui te retourne le nombre d'un produit p que tu peux fabriquer en fonction du produit p demandé. C'est bien ça que tu veux faire?

Entre nous, si c'est bien ça que tu veux faire, ce n'est qu'à mon sens qu'un exercice de style car cela va necessiter une requete qui va consommer du temps processeur à ton moteur mySQL. Quand il s'agit de faire des calculs sur des champs d'un seul enregistrement, je préfère de loin faire les calculs mathématiques en PHP, et reserver les requêtes complexes en terme de calcul quand tu fais des tris complexes sur des milliers d'enregistrement, bref, quand tu n'as pas le choix. Si il y a un conseil que je peux te donner c'est bien celui là, allège ton SGBDR le plus possible, ton application et le serveur ne s'en porteront que mieux.

Dernière modification par Jc (28-04-2010 10:36:07)

Maljuna Kris · 28-04-2010 13:29:05

Saluton,
+1 avec Jc, d'autant que, dans l'exemple que tu donnes, pour n'avoir qu'une seule ligne de résultat par produit, il te faudrait faire une jointure multiple entre la table composante et la table matières; multiplicité de jointure variable en fonction du nombre de composantes du produit, avec regroupement sur le produit.
Bref, c'est SQLment réalisable, mais quelle usine à gaz !

Pierrot · 28-04-2010 13:43:04

-1 avec tout le mond :D
une bonne proc stock devrai faire l'affaire

a++

moijhd · 28-04-2010 14:28:46

Hey !

Cela fait longtemps, je pensais plus avoir de réponses
C'était pour une petite application qui n'a finalement pas abouti, mais, puisque nous y sommes, j'aimerais quand bien résoudre le problème

D'abord par rapport avec vos réponses, il va me falloir quelques mots de vocabulaire :
- allège ton SGBDR
- une bonne proc stock

Tout de suite, je n'ai pas le temps de chercher mais je le ferais ce soir...

Ensuite, je crois que je me suis mal exprimé (ou que je n'ai pas compris la permière réponse )
On va tout d'abrod laisser de côté l'aspect temps de calcul et consommation (qui ne rentrent pas dans mon problème).
Aussi, pour les calculs mathématiques, c'est bien évidement comme ça que j'aurais procéder...mais je voulais faire sans, je voulais faire en SQL !

Je vais essayer de reprendre mes explications.

J'ai un produit P qui est fait à partir des quantités n_i de matière première M_i.
J'ai en réserve une quantité n_i_max de chaque matière première.
Je veux donc savoir combien je peux former de produits P.

:s ^^

Dernière modification par moijhd (28-04-2010 14:29:46)

Jc · 28-04-2010 19:22:12

SGBDR = Serveur Gestion Base de Données Relationnelle.

Alors pour éviter l'usine à gaz et avant de commencer à penser à la requête, la meilleure méthodologie est l'approche mathématique, en trouvant l'algorithme mathématique minimaliste et donc optimisé pour résoudre ton problème. Une fois réalisé, reste plus qu'à construire ta requête. Je ne te conseille pas de faire l'inverse, sinon rendez vous dans 10 ans?^^

moijhd · 28-04-2010 20:20:16

Oui, enfin il n'y a pas une infinité de méthodes :
1. Je récupere les quantité n_i des matières premières necessaires à la fabrication de mon produit
2. Je récupre les quantités disponibles n_i_max de chacune des matières premières
3. Je calcule les rapports r_i = n_i_max / n_i que j'arrondis à l'entier inférieur
4. Je retourne le plus petit rapport.
C'est l'algorithme naif.

Maljuna Kris · 28-04-2010 21:59:24

Rappel :
La vraie difficulté n'est pas dans l'algorithme ni dans la conception de la requête. La difficulté réside dans la variabilité du nombre de jointures à réaliser, variabilité correspondant au nombre variable des composantes d'un produit.

Jc · 28-04-2010 23:29:07

La vraie difficulté n'est pas dans l'algorithme ni dans la conception de la requête. La difficulté réside dans la variabilité du nombre de jointures à réaliser

Comment dire une chose et son contraire dans la même ligne

Donc vous l'aurez compris, je suis pas d'accord^^, c'est un tout et faut rien négliger. Bien que ta structure base de données soit bonne, elle n'est pas adaptée a ton algo, si tu veux rester sur celui que tu exposes, je pense que le plus rapide est de passer par une table temporaire, qui evitera trop de consomation de ressources.

++ go dodo

Re: J'allais pour m'endormir, quand j'ai réalisé la simplicité du truc.. j'en ai honte. Donc désolé

C'est tellement facile, que je vous donne la solution en suivant l'algo de notre ami. (donc désolé d'avoir dit que ton algo collait pas à la structure. Ce qui m'a mis la puce à l'oreille c'est que ta structure etait la meilleure possible. Donc je vous fait plus languir...

SELECT composantes.id2, quantité,stock, stock/quantite AS rpQS

FROM composantes, matieres

WHERE composantes.id2 = matiere.id2 AND composantes.id1=1

ORDER BY rpQS ASC limit 1

Le champ rpQS sur la seule ligne de retour te donne la solution. Et hop, affaire réglée.:D

Dernière modification par Jc (29-04-2010 00:33:34)

moijhd · 29-04-2010 07:57:57

Je suis presque déçu ! Je voulais quelque chose de plus compliqué...:p
Mais je vais tester dans la journée et attendre d'autres remarques ^^

Merci.

Maljuna Kris · 29-04-2010 11:29:35

Jc a écrit :

La vraie difficulté n'est pas dans l'algorithme ni dans la conception de la requête. La difficulté réside dans la variabilité du nombre de jointures à réaliser
Comment dire une chose et son contraire dans la même ligne
Donc vous l'aurez compris, je suis pas d'accord^^, c'est un tout et faut rien négliger. Bien que ta structure base de données soit bonne, elle n'est pas adaptée a ton algo, si tu veux rester sur celui que tu exposes, je pense que le plus rapide est de passer par une table temporaire, qui evitera trop de consomation de ressources.
++ go dodo
Re: J'allais pour m'endormir, quand j'ai réalisé la simplicité du truc.. j'en ai honte. Donc désolé
C'est tellement facile, que je vous donne la solution en suivant l'algo de notre ami. (donc désolé d'avoir dit que ton algo collait pas à la structure. Ce qui m'a mis la puce à l'oreille c'est que ta structure etait la meilleure possible. Donc je vous fait plus languir...
SELECT composantes.id2, quantité,stock, stock/quantite AS rpQS
FROM composantes, matieres
WHERE composantes.id2 = matiere.id2 AND composantes.id1=1
ORDER BY rpQS ASC limit 1
Le champ rpQS sur la seule ligne de retour te donne la solution. Et hop, affaire réglée.:D

Si cette requête donne le résultat escompté, je mange mon chapeau.
Outre que la syntaxe normalisée des jointures SQL, depuis 1992, passe par la famille JOIN, je ne vois pas ce qui va permettre de ne s'occuper que des composantes d'un produit.
Chaque produit ayant un nombre indéterminé de composantes, la difficulté réside dans l'automatisation du nombre de jointures à opérer entre la table composante et la table matiere, pour chaque produit.
Ce que, à l'évidence, ne réalise pas cette requête.

Jc · 29-04-2010 11:59:33

J'espère que t'as une webcam pour voir ca, suis impatient
Faut travailler à partir de la table de jonction comme j'ai fait pour associer à chaque composant le stock correspondant et faire le rapport pour chaque composant entre la valeur stock et la quantité necessaire. Ensuite pour avoir le plus petit, on trie l'ensemble des lignes par ordre croissant ainsi le premier enregistrement correspond au facteur limitant.

Si tu retires le Limit 1 la requete va te retourner autant de lignes que de composants pour ton produit. Seule la première après le tri nous interesse.

Dernière modification par Jc (29-04-2010 12:01:14)

Maljuna Kris · 29-04-2010 12:09:55

Comme quoi la lisibilité de la syntaxe normalisée est bien meilleure:

SELECT composantes.id2, quantité,stock, stock/quantite AS rpQS

FROM composantes

INNER JOIN  matieres ON composantes.id2 = matieres.id2

WHERE composantes.id1=1

ORDER BY rpQS ASC LIMIT 1

Car ton filtrage sur composantes.id1=1 ne m'était pas apparu.
Donc, chapeau ! (que je ne mange pas)

Pierrot · 29-04-2010 12:19:54

c'est pour ca que je dis qu'une bonne proc stock, c'est l'idéal
a++

Jc · 29-04-2010 19:30:17

Enfin dans ce cas là pierrot, et pour assouvir l'espérance d'une requête plus complexe de l'auteur, l'avantage de la requête en la modifiant et en faisant une recherche par le nom de produit à fabriquer plutot que par son index, et en rajoutant un champ pour nommer le composant, on connait non seulement combien on peut en faire mais en plus la requête te dit ce qu'il faut aller acheter pour en faire plus. Mais par contre elle ne fait pas le café^^ .

Concernant la normalisation des requêtes SQL avec la syntaxe JOIN (que j'utilise encore uniquement quand j'ai besoin d'un LEFT ou d'un RIGHT JOIN (c'est à dire pas souvent)) je suis d'accord avec Maljuna sur son utilisation, mais son utilisation demeure vite complexe sans générateur de requêtes pour des tâches qui restent relativement non complexes, et de plus elle à des limitations que mySQL à pris en compte et les a étendue pour en faire sa particularité et sa puissance. J'écris donc mes requêtes en mySQL et non pas en ANSI SQL92 ce qui me permet aussi (outre l'exploitation optimum de ce que peut m'offrir ce SGBDR) d'écrire des requêtes complexes à la volée sans me tromper. Essaye de developper en ANSI SQL92 sur une base JET SQL.. C'est vrai qu'avec mySQL c'est plus facile car il intègre de base le standard.

Donc c'était un simple avis, et si ca peut profiter à une majorité tant mieux.

Dernière modification par Jc (29-04-2010 19:43:20)

PHP|Débutant :: Forums

Advertisement

#1 14-03-2010 15:17:56

Compter le nombre de possibilité

#2 28-04-2010 09:41:20

Re : Compter le nombre de possibilité

#3 28-04-2010 13:29:05

Re : Compter le nombre de possibilité

#4 28-04-2010 13:43:04

Re : Compter le nombre de possibilité

#5 28-04-2010 14:28:46

Re : Compter le nombre de possibilité

#6 28-04-2010 19:22:12

Re : Compter le nombre de possibilité

#7 28-04-2010 20:20:16

Re : Compter le nombre de possibilité

#8 28-04-2010 21:59:24

Re : Compter le nombre de possibilité

#9 28-04-2010 23:29:07

Re : Compter le nombre de possibilité

#10 29-04-2010 07:57:57

Re : Compter le nombre de possibilité

#11 29-04-2010 11:29:35

Re : Compter le nombre de possibilité

#12 29-04-2010 11:59:33

Re : Compter le nombre de possibilité

#13 29-04-2010 12:09:55

Re : Compter le nombre de possibilité

#14 29-04-2010 12:19:54

Re : Compter le nombre de possibilité

#15 29-04-2010 19:30:17

Re : Compter le nombre de possibilité

Pied de page des forums