Ou placer la logique metier?

Bonjour,
je veut concevoir une application VB.Net/MySQL pour la gestion de stock.
Sur la base j'ai deux tables
Stock(Ref,Quantité))
Mouvement(Ref,Date, Quantité, entré/sortie)
A chaque fois j'ai une entrée ou une sortie de stock j'insère la ligne correspondante dans la table mouvement . Les quantités dans la tables Stock doivent se mettre a jour conformément aux lignes ajoutés.

J'ai deux choix (a ma connaissance) pour concevoir cette application:
1- Créer un trigger sur la table Mouvement qui met a jour les quantité de la table Stock
2- Gérer le problème avec des fonctions locales (dans l'application .Net)

Un deuxième besoin c'est de déterminer est ce que le stock est "suffisant" ou non.
Je dois avoir un fonction qui a comme entrée une liste des éléments (Ref,Qty)
et qui renvoie une valeur booléenne pour dire est ce que le stock est suffisant ou non.
Toujours le même soucis: ou mettre la fonction
1- Une fonction dans la base de donnée en PL/SQL
2- Une fonction locale en .Net qui charge la table stock entière et effectue la vérification.

Merci d'avance pour vos conseils

Citation:

---

J'ai deux choix (a ma connaissance) pour concevoir cette application:
1- Créer un trigger sur la table Mouvement qui met a jour les quantité de la table Stock
2- Gérer le problème avec des fonctions locales (dans l'application .Net)

---

La première solution est plus sûre, moins coûteuse en traffic réseau et probablement plus rapide avec un grand nombre de données.

Citation:

---

Un deuxième besoin c'est de déterminer est ce que le stock est "suffisant" ou non.
Je dois avoir un fonction qui a comme entrée une liste des éléments (Ref,Qty)

---

Tu veux dire : la liste des produits à sortir du stock pour satisfaire une commande ?

Citation:

---

et qui renvoie une valeur booléenne pour dire est ce que le stock est suffisant ou non.
Toujours le même soucis: ou mettre la fonction
1- Une fonction dans la base de donnée en PL/SQL
2- Une fonction locale en .Net qui charge la table stock entière et effectue la vérification.

---

Si tu as des milliers, voire dizaines de milliers, de produits en stock, je pense que ça va faire un peu lourd là aussi en mémoire, en traffic réseau, en traitement par ta fonction.
Il suffit de créer une requête de ce type pour savoir si la commande peut être satisfaite :

Code:

---

1 2 3

SELECT stk_id_produit, stk_ref_produit, stk_quantite FROM stock WHERE stk_ref_produit IN ('ref1', 'ref2', 'ref3')

---

Tu n'auras alors que le nombre de lignes correspondant au nombre de produits dans la commande pour faire ta comparaison aux quantité commandées.

Bonjour,

Merci pour la réponse, mon majeur probleme c'est le temps d'allé retour de requetes non pas de point de vue performance mais

Si par exemple un client veut lancer une commande , la panier est composé d'une liste de (Reference, Quantité), l'operation se deroule comme suit:

1. Lancement de commande
2. Verification de la disponibilité des articles en quantités suffisantes
3. Mise a jour de la table (mise ajour des quantités restantes))

Le probleme apparait lorque un client verifie la disponibilité et avant que la mise a jour des tables soit effectué le contenu de la table est mis a jour ce qui pourra rendre la disponibilité plus vraie. Ce probleme apparait surtout dans le cas ou la logique metier est au niveau client. parce que l'instant t1 et t3 sont séparé par le temps d'allé retour de requetes. et étant donné que la base de donnée est hebergé sur internet cet inetrvalle peut etre assez important ce qui rendra le probleme assez fréquent.

Ceci est shématisé dans le diagramme de séquence dans la piece jointe.
Pourtant dans le cas ou on utilise des procedures sur le serveur(case2) l'intervalle t2-t1 est relativement court en plus on peut verrouiller le lignes en question.
Qu'en pensez vous?

C'est bien pour ça que le trigger est meilleur.
Tu lances la requête qui va insérer une nouvelle commande et le trigger vérifie que la quantité est disponible avant d'insérer la commande. Pendant ce temps, la table est bloquée pour les autres insertions.

Par contre, si tu as un autre processus qui peut mettre à jour la table du stock, il faudrait aussi la bloquer pendant le trigger car il ne le fera pas tout seul.