MySQL - Query ou storeproc?

[Yoshi]

[align=justify:9edd3fff38]J'utilise une base de donné MySQL pour tenir l'inventaire du commerce à ma conjointe et je sais pas trop comment m'y prendre pour compiler l'inventaire. J’ai deux tables. Une pour les achats et une pour les ventes. Les deux tables ont, entre autre, les champs ItemId, Date, Prix et Quantity. Donc quand j’achète du stock, j’entre un record dans la table achats pour chacun des type d’article acheté. Même chose lors d’une vente. Maintenant, je veux être capable de calculer la valeur de mon inventaire et c’est là que ça m’embête car il peut y avoir des prix d’achat différent pour un même type d’article. Et je dois utilisé le prix des articles le plus récement achetés. Je donne un exemple pour un article en particulier…[/align:9edd3fff38]

Table Achat
ItemId.......Date.................Prix............ Quantity
5...............30/01/07..........10.00..........3
5...............29/06/07..........11.00..........4
5...............26/10/07..........12.00..........5

Table Vente
ItemId.......Date ............... Prix............Quantity
5...............20/12/07..........25.00..........2
5...............21/12/07..........25.00..........4

[align=justify:9edd3fff38]Donc j’en ai acheter 12 et vendu 6. Il m’en reste donc 6 en stock. Jusqu’à là, c’est assez simple. Mais pour calculer la valeur de l’inventaire, je dois utilisé la valeur unitaire des 6 derniers articles achetés (rotation des stock). Donc la valeur de l'inventaire sera de 5x12$ + 1x11$ = 71$.

Il serait possible d’utilisé une query pour faire ce calcul? À première vue et avec mes connaissance des différentes functions, je vois pas ben ben comment. Une store proc serait plus appropriée?[/align:9edd3fff38]

[Yoshi]

Problème résolu. Merci!

[morceau]

c'etais facile anyway :P

[titienne]

Au pire, ajoute toi un champ de type identity. Ca vas te donner dans l'order d'achat ( ou vente) de la table.

Ti truc

[Born2bWild]

Envoyé par titienne

Au pire, ajoute toi un champ de type identity. Ca vas te donner dans l'order d'achat ( ou vente) de la table.

Ti truc

Ti-truc qui n'sert absolument à rien dans la résolution du problème puisque l'ordre d'achat n'affecte en rien le calcul qu'il veut faire... La preuve, il a atteint son but...

Mais par contre, en admettant que son exemple reflète sa réalité, au niveau "design", il y a une lacune majeure: aucune clé primaire n'est possible pour permettre d'atteindre un enregistrement en particulier... Donc oui, un champs de type "identity" aurait été un approprié...

Bref, on pourrait élaborer la situation encore plus loin puisqu'une vente à toujours un numéro de facture unique (cléprimaire) et qu'un achat a aussi un numéro de facture unique jumellé à un fournisseur unique (cléprimaire aussi)... Donc champ ID non obligatoire mais ayant ses avantages et ses désavantages...

[Yoshi]

Envoyé par Yoshi

Les deux tables ont, entre autre, les champs ItemId, Date, Prix et Quantity.

Comme je disais, mes tables on d'autre champs. Dont une clé primaire.

[titienne]

t DBA ?
lol