Discussion :

[mbsl1]

Bonsoir, J'aurai souhaité un retour d'expérience, conseil sur une structure SQL correspondant au besoin vulgarisé suivant :

Prenons l'exemple d'un spectacle se déroulant quotidiennement avec une trentaine de séances par jour. (La capacité globale est portée à 10000 : Seance.Se_jaugeglobale = 10000)
Lors de la réservation du spectable tant que celle-ci n'est pas confirmée par un paiement, nous devons bloquer la quantité demandée afin de ne pas provoquer un surbooking. (Panier moyen de 5 personnes ; PanierContenu.Pc_quantite = 5 ; V_SeanceRestante.Sr_jaugerestante = 9995)
Le panier peut-être abandonné par l'internaute ou libéré automatiquement au bout de x minutes d'inactivité. (Via Delete du Panier en question)
Une fois confirmé par son paiement, le panier est supprimé et transformé en vente effective ; la jauge est recalculée dans la table Séance. (Seance.Se_jaugeglobale = 10000, VenteContenu.Vc_quantite = 5, V_SeanceRestante.Sr_jaugerestante = 9995)

Actuellement, nous utilisons une vue SQL pour fournir la disponibilité restante

Structure allégée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
CREATE SCHEMA [test]
GO
 
CREATE TABLE [test].[Seance](
	[Se_id] [bigint] NOT NULL,
	[Se_dhdebut] [datetime] NOT NULL,
	[Se_dhfin] [datetime] NOT NULL,
	[Se_jaugeglobale] [int] NOT NULL,
	[Se_jaugeventes] [int] NOT NULL)
GO
 
CREATE TABLE [test].[Vente](
	[Ve_id] [bigint] NOT NULL,
	[fk_poste] [bigint] NULL,
	[fk_operateur] [bigint] NULL,
	[Ve_dhcreation] [datetime] NULL)
GO
 
CREATE TABLE [test].[VenteContenu](
	[Vc_id] [bigint] NOT NULL,
	[fk_vente] [bigint] NULL,
	[fk_seance] [bigint] NULL,
	[Vc_quantite] [int] NULL)
GO
 
CREATE TABLE [test].[Panier](
	[Pa_id] [bigint] NOT NULL,
	[fk_poste] [bigint] NULL,
	[fk_operateur] [bigint] NULL,
	[Pa_dhcreation] [datetime] NULL)
GO
 
CREATE TABLE [test].[PanierContenu](
	[Pc_id] [bigint] NOT NULL,
	[fk_panier] [bigint] NULL,
	[fk_seance] [bigint] NULL,
	[Pc_quantite] [int] NULL)
GO
 
CREATE VIEW [test].[V_SeanceRestante] AS
SELECT
	se.Se_id as fk_seance,
	se.fk_salle,
	se.Se_dhdebut as Sr_datedebut,
	se.Se_dhfin as Sr_heurefin,
	isnull(se.Se_jaugeglobale,0) as Sr_jaugeglobale,
	isnull(se.Se_jaugeglobale,0)-isnull(se.Se_jaugeventes,0)-isnull(TAB_pc.Se_jaugepaniers,0) as Sr_jaugerestante    
FROM 
	[test].[Seance] se
  	LEFT JOIN (select pc.fk_seance, SUM(Pc_quantite) as Se_jaugepaniers from [test].[PanierContenu] pc group by pc.fk_seance) AS TAB_pc ON TAB_pc.fk_seance = se.Se_id 								
GO

Nous avions choisi ce modèle afin d'éviter trop d'écritures dans la table Seance qui est déjà fortement sollicitée sur l'update de la colonne Seance.Se_jaugeventes.


Nous rencontrons cependant ponctuellement des latences (20 secondes maxi) lors de la consultation de cette vue et systématiquement proportionnelles au nombre de paniers ; la libération automatisée de paniers abandonnés toutes les x minutes (DELETE Paniers dont la durée de vie est supérieure à x minutes) provoquent également des latences. Le modèle présentée est allégée, nous gérons des sous niveaux permettant de privatiser spécifiquement une partie de la jauge globale à certains canaux de ventes en fonction de x critères, etc... Une vue est également présente pour les sous-niveaux.


Une des hypothèses envisagées serait d’éprouver le stockage de la somme des quantités correspondants aux paniers également dans la table Séance et ainsi d'éviter l'utilisation de la vue.

Pourriez-vous me fournir des pistes sur ce sujet ? Quels seraient le modèle idéal selon vos retours d'expérience (Une refonte pourrait-être envisageable)

En vous remerciant par avance.

[Invité]

Pas de clefs primaires, d'indexes et de clefs étrangères ?

[mbsl1]

Bonjour, comme évoqué il s'agit d'une structure allégée ; nous avons une PK Clustered par table, des FK systématique, et différents index ajoutés de manière empirique en fonction des consultations des statistiques SQL et de l'efficience apportée.

[SQLpro]

Sans aucune contrainte votre système va s'auto bloquer…..

Pour être efficace un système de vente à stock défini, comme c'est le cas des places de spectacle ne devrait pas avoir de notion de panier, mais travailler directement sur un état des places vendues pour un événement.

Une place dans une salle à une date peut être vendue, en cours d'achat, libre. Le seul pilotage de cet état avec des références au client suffit et simplifie toutes les requêtes.
Vous pouvez enfin, ajouter une vue indexées pour l'état du stock (libre, en cours d'achat, acheté).

A +

[mbsl1]

Merci pour ces différentes réponses,

Point 1 : Qu'entendez-vous par "Sans aucune contrainte votre système va s'auto bloquer" ? Si vous parlez de la structure allégée, celle-ci ne présente effectivement par les PK, FK, UK que nous avons sur notre structure réelle. Ces contraintes sont donc bien existantes à ce jour.
Point 2 : Notre produit ne réalise pas systématiquement de placement physique au numéro de place prêt (j'ai peut-être induit votre réponse sur mon premier message) ; en reprenant ma structure allégée, qu'indiqueriez vous pour gérer uniquement cette partie de stock qui est réservée via les paniers. Stockage physique de la somme des qté de paniers dans la table séance ou Vue indexée décrementant les Paniers en cours ?

Merci de vos retours