Bonsoir à tous,
 
Je suis en train de dev une appli eCommerce. Sur la page d'affichage du panier, 2 requêtes SQL sont faite pour chaque article présent (afin de faire diverses vérifications pour chacun d'eux).
 
Le site pour lequel je le developpe ne fera pas de gros paniers (2 ou 3 articles grand max) donc ça ne pose pas trop de problème.
 
Par contre, j'essaye de faire un truc vraiment super complet, et très sécurisé, et si au final l'appli est sympa, je la mettrai surement à disposition de tout le monde. Mais si un site venait à l'utiliser et faisait des paniers de 50 articles par exemple, ça ferait 100 requêtes SQL Je trouve ça assez enorme, mais j'ai beau retourner le problème dans tous les sens, je ne vois pas comment "optimiser" ces vérifications encore plus que je ne l'ai déjà fait.
 
Qu'en pensez-vous ? Je ne sais pas trop quelle charge represente ces requêtes. Est-ce vraiment surdimensionné ? Faut il absolument que je trouve un autre moyen quitte à laisser tomber quelques verifications ?
 
Merci par avance, de mon côté je vais quand même vois si je ne trouve pas un moyen de rappatrier à l'avance les données qu'il faut, et faire mes tests sur des array(), mais ça va me faire reprogrammer une bonne partie du script (voir la quasi-totalité vu que j'ai déjà pas mal de pages).
 
A+

Explique nous peut-être plus pourquoi il est indispensable de faire 2 requete pour chaques articles ...

théoriquement il en faut plus que 2:
-locker la table
-vérifier que larticle est dispo
-réserver l article
-délocker
Mais tu peut le faire qu une seule fois lorsque le client mets l article dans le caddie

en meme temps si la requete est "SELECT quantite FROM stock WHERE idArticle=$id" >> ca coute pas grd chose
 
si par contre, tu te retrouve avec des jointure, des groupby , sum ,... ca devient moins propre
 
tu peux aussi faire un truc du genre  
select id from stocks where id in($id1,$id2,$id3,....) AND stock=0
une requete et tu sais quels articles sont en rupture

 
vi, ça nous éclairerait un peu

En fait, lorsqu'on affiche le panier, pour chaque article en gros on vérifie s'il est toujours en vente (stock, mise en ligne, rupture provisoire/definitive etc...) ainsi que si la catégorie dans laquelle se trouve l'article est toujours signalée comme 'en vente'. Car on aura la possibilité, côté administration, de virer toute une catégorie de la vente momentanément (c'est pour les besoins du site dont je m'occupe).
 
Pour ce qui est de "select id from stocks where id in($id1,$id2,$id3,....) AND stock=0 " je connais en effet, mais c'est une fonction que j'ai faite qui s'occupe de faire toutes les verifs. Mais j'ai commencé à recoder toute cette partie, je vais faire d'abord une requete qui va aller chercher la liste de tous les articles du paniers, puis balancer un array des ID de chaque article, et une boucle qui fera la verification pour chaque ID, et retournera egalement un array, avec lequel je construirai la table à afficher ...
 
Je sais pas si je suis assez clair mais il est tard et je vais me coucher
 
Merci à tous

à mon avis tu ferais mieux de vérifier ça une seule fois au moment de payer
 
tu vas faire un paquet de requêtes inutiles pour pas mal de gens qui vont remplir des paniers sans jamais aller plus loin
 
idem pour ton stock, si je surfe avec 20 trucs dans mon panier sans jamais les acheter ? ils sont plus dispos pour les autres ?
 

> ils sont plus dispos pour les autres ?
ben ouais, à moins que le client accèpte de faire ses courses pendant 1 heure et de ne pas pouvoir tout acheter à la fin.
 
Je maintiens que la vérification des stocks ne devrai pas se faire au passage à la caisse, mais à l ajout/retrait d articles au caddie. Ça fluidifie déjà le traffic des requêtes.
 
L affichage du caddie lui même est un simple select:
select * from caddies where userid=blabla;
mais gare à l index sur le champs userid.
 
Le caddie devrait être sauvegardé dans une table à part s il doit être gardé lorsque le client se déconnecte sans payer (ça dépends aussi des articles dedans).
 
Reste à prévoir un backoffice pour faire le ménage dans les caddies abandonnés depuis trop longtemps  
(ça dépends aussi des articles dedans).

pour moi ce truc est valable uniquement si tu vends des articles que tu as en grande quantité, sinon tu laisse la possibilité qu'un client ne puisse acheter qq chose car une autre l'a déjà dans son panier
 
faut pas négliger le nombre de commandes jamais finalisées, et autre problème de provision sur CB etc etc

Cet eCommerce est prévu pour de l'artisanat, donc les objets sont fabriqués à la demande, donc il n'y a pas de gestion de stock pour le moment (je l'ajouterai quand même par la suite si je veux distribuer l'appli).  Donc le panier permanent n'est pas un problème.
 
Mais je vais coder des paramètres pour gérer la durée de ces paniers, lorsque j'aurai mis en place la gestion de stock. Soit une durée "infinie" (donc panier permanent) soit un délai au choix. (Par exemple si on défini une durée de 2 heures, tous les articles dans le panier depuis + de 2 heures seront invalidés et repasseront en stock. Ils apparaitront tjs dans le panier mais en quantité 0 avec une petite icône d'avertissement si l'utilisateur veut le garder dans son panier il devra revalider chaque article invalide.
 
Enfin bon, ce ne sont que des idées sur le tapis pour le moment, c'est amené à changer. Il me reste encore beaucoup de boulot.
 
Donc d'après vous, je devrais faire la verification de disponibilité d'un article uniquement à la commande ? Et pas dans le panier ?
 
Car comme je l'ai dis, c'est un panier permanant. Une personne peut très bien mettre deux articles aujourd'hui, et puis va demander à son oncle s'il n'en voudrais pas un aussi, et reviens 2 jours après ... Si entre temps le produits n'est plus fabriqué, j'aimerais que l'info apparaisse dans le panier...
 
Sinon pour la suite, lorsque j'aurai developpé la partie gestion de stock, je pense que le site affichera ça sous la forme Stock : 5 (3) qui voudra dire qu'il reste 5 produits en stock, et 3 produits en attente (dans les paniers). Bien evidement, l'activation dans les options de la gestion de stock sera "incompatible" avec le panier permanent. Mais ça permet d'informer les gens. Si le délai des paniers est reglé sur 2 heures par exemple et qu'un article leur plait, mais que le stock affiche 0 (2), ils pourront soit le reserver définitivement (et passer la pré-commande), soit le reserver temporairement (ce qui veut dire que si un des 2 articles en cours dans les paniers est à nouveau dispo, et que quelqu'un l'a reservé, il passera dans son panier pour une durée de 2 heures et un mail lui sera envoyé. Bien evidement ceux ayant déjà payé auront un niveau de priorité plus elevé.
 
Enfin bref, c'est pas trop le sujet, je m'emporte
 
Bon en tout merci à tous, une nouvelle journée commence, et je vais me replonger la dedans pour décider de la meilleure décision.
 
A+

j'avais pensé à un système de ce genre, mais ça me posait beaucoup trop de contraintes pour au final un gain négligeable
 
tu t'imagine pas le nombre de paniers qui sont remplis sans jamais être payés (frais de port dissuasifs, paiement qui déconne, CB sans provision etc  etc), sur des articles en petite série, t'as vite fait d'être en rupture avant d'en avoir vendu un seul..
 
si en plus un gars en commande 10, paye, et annule derrière par mail, entre ce moment là et celui ou l'admin aura annulé ça risque de coincer
 
et des cas comme ça y'en a pas mal (surtout si le site marche bien..)
 
moi je préfère qu'un client commande qu'on lui dise "cet article est en rupture, désolé on vous rembourse" (si il a commandé autre chose il annulera peut être pas tout, et ça montre la réactivité du site) plutôt qu'il commande rien du tout parce qu'il n'a pas trouvé ce qu'il cherchait (et si en plus les 3 autres clients qui l'ont bloqué n'ont pas payé non plus t'es marron), mais c'est un choix commercial plus qu'autre chose
 
 
 
 
 

Donc le mieux serait juste d'afficher "En stock" si au moins un article est dispo et de retirer les articles du stock uniquement lorsque la commande est payée ?
 
Et par conséquent faire la vérification du stock au moment de l'achat...
 
C'est peut être pas plus mal en effet. Je vais voir.

 
 
y'a pas de meilleure solution, mais un choix à faire en fait