Tu t'es baladé sur les exercices précédents ? Ok, alors je vais te donner un truc un peu plus corsé. On passe à la consolidation de tes skills en PL-SQL et à l'écriture de procédures et de triggers. Prêt ?
Création de procédures
Voici des procédures qu'il est recommandé d'ajouter à la base de ta marketplace. Chaque procédure est accompagnée d'une explication sur les tâches et process business qu'elle gère et pourquoi ça vaut le coup de la mettre en place. Ces procédures couvrent l'automatisation des opérations clés, l'amélioration de l'expérience utilisateur, l'optimisation de la vitrine, de la logistique, du support, du marketing et de l'analytics.
1. Passer une commande avec réservation automatique des produits
Passer une commande, c'est l'opération centrale de n'importe quelle marketplace. La procédure doit non seulement créer l'enregistrement de la commande et ses lignes, mais aussi réserver le stock, décrémenter la quantité, fixer le statut, lancer le paiement et déclencher les process suivants (notifications, logistique). Automatiser ce scénario réduit les risques d'erreurs manuelles, évite le over-selling et garantit la cohérence des stocks en temps réel.
2. Automatisation du réapprovisionnement des stocks
Pour éviter le out-of-stock et la perte de ventes, il faut réapprovisionner à temps si le niveau de stock passe sous un seuil. Cette procédure vérifie les stocks de tous les produits, les compare au minimum et génère automatiquement des demandes d'achat ou de réassort interne. L'automatisation accélère la réaction et réduit la charge manuelle sur l'équipe opérationnelle.
3. Mise à jour massive des statuts de commandes et notification des clients
Dans le catalogue, il faut souvent changer en masse les statuts des commandes (genre “payé” → “expédié” ou “expédié” → “terminé”) selon l'étape de traitement. La procédure met à jour les statuts de toutes les commandes concernées, écrit l'historique des changements (pour l'audit) et peut déclencher l'envoi de notifications aux clients. Ça automatise le back-office et limite les erreurs humaines.
4. Application massive de remises/promo codes sur les produits
Pour booster les ventes ou lancer des promos, il faut souvent appliquer des promo codes ou des remises à toute une catégorie, une marque ou une sélection de produits. La procédure applique automatiquement les remises, gère les limites (date, quotas), met à jour les compteurs d'utilisation et évite les doublons.
5. Remboursement automatique à l'utilisateur
Gérer les retours et les remboursements, c'est crucial pour la confiance client. La procédure doit vérifier le statut de la commande, la validité du retour, lancer le remboursement, mettre à jour les statuts, logger la transaction et notifier l'utilisateur. Tout faire dans une seule transaction réduit les risques d'erreurs et d'abus.
6. Recalcul de la note moyenne d'un produit / vendeur
À chaque nouvel avis, modif ou suppression, la note moyenne du produit ou du vendeur doit être à jour. La procédure recalcule et met à jour le champ “avg_rating”/“review_count” pour accélérer les requêtes côté front et garantir la cohérence des analytics.
7. Désactivation automatique des produits avec stock à zéro
Pour que la vitrine de la marketplace tourne bien et éviter les mauvaises surprises aux clients, les produits avec stock à zéro doivent être automatiquement cachés (désactivés). La procédure vérifie régulièrement les stocks et le statut des produits, passe le statut à “inactive”, logge le changement et garde le catalogue à jour sans vérif manuelle.
8. Attribution automatique d'une commande à un livreur et mise à jour du statut de livraison
En logistique, il faut assigner vite et clairement un livreur à une commande, changer le statut de livraison, tout tracer pour le suivi. La procédure automatise ces étapes et évite le taf manuel du manager.
9. Envoi massif de notifications aux utilisateurs (promo, rappels)
Les notifications sur les soldes, retours, changements de statuts ou actions marketing doivent partir en masse, selon des critères (utilisateurs actifs, pas acheté depuis longtemps, panier abandonné, etc.). La procédure permet de lancer l'envoi de push/email à un segment donné.
10. Archivage des données obsolètes (genre commandes terminées ou produits inactifs)
Pour garder de bonnes perfs sur la base et alléger les tables “chaudes”, les vieux enregistrements (anciennes commandes, produits archivés, vieux tickets support) doivent être régulièrement déplacés ou marqués “archive”. La procédure facilite la suppression ou le déplacement des données et limite le taf manuel des admins.
Création de triggers
1. Logging du changement de statut d'une commande
Garder tout l'historique des statuts de commandes, c'est vital pour l'audit, le support, l'analytics et l'envoi auto de notifications aux clients sur l'avancement de leur commande. Le trigger crée automatiquement une entrée dans "order".order_status_log à chaque changement de statut, sans que les devs aient à gérer l'historique côté app.
2. Historique auto des changements de prix d'une variante produit
L'historique des prix sur les SKU est nécessaire pour l'analytics, afficher “l'ancien prix”, suivre les promos et envoyer des notifications auto sur les baisses. Le trigger enregistre chaque changement du champ price dans la table product.variant dans l'historique product.price_history. Ça permet de garder toute la dynamique des prix sans erreurs ni oublis.
3. Synchronisation du stock lors des changements sur l'entrepôt
Chaque modif de stock (genre inventaire, réception, sortie) doit mettre à jour automatiquement le champ last_updated pour une analytics correcte et garder les données fraîches. Ce trigger peut aussi lancer une vérif du seuil mini et déclencher un auto-achat.
4. Désactivation auto des variantes produit avec stock à zéro
Pour éviter qu'un client achète un produit indisponible, dès que le stock tombe à zéro sur tous les entrepôts pour une variante, son champ is_active passe à FALSE. Ça réduit les avis négatifs et les annulations.
5. Logging des tentatives de connexion admin (sécurité)
Contrôler les connexions admin, c'est la base de la sécu. Toutes les tentatives (réussies ou non) sont loggées dans admin.login_attempt via un trigger BEFORE INSERT. Ça permet de repérer vite les attaques, hacks ou comportements suspects.
6. Logging des changements clés sur un produit et historique auto
Toutes les modifs importantes d'un produit (statut, description, nom) doivent être tracées pour l'audit des actions staff, corriger les erreurs et éviter les abus. Le trigger crée une entrée dans product.status_history à chaque changement de statut et peut être étendu à d'autres champs clés.
7. Mise à jour auto du compteur d'utilisation d'un promo code
Bien compter le nombre d'utilisations d'un promo code, c'est important pour limiter les promos et éviter les abus. Le trigger, à chaque insert dans marketing.promo_usage, incrémente le compteur used_count dans marketing.promo_code, évitant les incohérences.
8. Mise à jour du solde du wallet utilisateur lors des transactions
Pour afficher le bon solde du wallet bonus/cashback d'un utilisateur, chaque transaction doit mettre à jour automatiquement le solde final dans payment.wallet. Un trigger sur l'insert d'une nouvelle transaction réduit les risques de perte ou d'erreur de données côté app.
9. Mise à jour auto de l'adresse, email ou téléphone “principal”
Pour éviter qu'un utilisateur n'ait pas d'email/téléphone/adresse principal (super important pour la récup d'accès et la comm), le trigger met auto le flag is_primary=TRUE sur le premier enregistrement si aucun n'existe, et garantit l'unicité pour chaque utilisateur.
10. Calcul de la note moyenne d'un produit à chaque nouvel avis
Pour afficher vite la “note moyenne” sur la fiche produit et en recherche, mettre à jour cette valeur à chaque nouvel avis est plus efficace que recalculer tout le temps avec des requêtes. Le trigger maintient le cache du champ avg_rating et/ou review_count dans product.product.
11. Mise à jour auto de la date de publication du contenu
Pour les articles, pages ou autres publications, quand le statut passe à “published”, il faut bien remplir le champ published_at. Ça garantit l'intégrité du CMS : users et admins voient la vraie date de sortie, et le front n'a pas besoin de maj manuelle en plus.
12. Logging de tous les events support (changements de statut de ticket)
L'historique complet des demandes support et des changements de statut permet d'évaluer le taf du support, faire de l'analytics et garantir la transparence pour les users. Le trigger écrit automatiquement une entrée dans support.ticket_status_log à chaque changement de statut de ticket.
Remarque
Ajouter ces triggers va vraiment booster la fiabilité, la transparence et l'automatisation des process business clés de ta marketplace, alléger le code applicatif et garantir l'intégrité des données au niveau de la base. C'est du best practice pour le design des systèmes relationnels dans le gros e-commerce.
GO TO FULL VERSION