PHP|Débutant :: Forums

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 !

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)

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.

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

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)

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.

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

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

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)