Site de location de vélo

Version imprimable

23/07/2018, 16h53
droledenm

Site de location de vélo

Bonjour,
Je souhaite faire un service de reservation avec une base SQL mais ce que j'ai en tete ne me parait pas tres optimal et j'aimerais avoir vos conseils.

J'ai un site (Wordpress) pour de la location de velo.
Sur mon hébergeur, je peux mettre PHPMyAdmin et sur une base MySQL je veux mettre ma réservation de vélo.
Pour ca, je vois bien 1 table par vélo (V1, V2, V3,...) et pour chaque velo une colonne 07h - 08h - 09h -... 20h que je remplis avec le nom de l'utilisateur
Je veux pouvoir réserver sur la semaine en cours et la semaine suivante ce qui m'oblige a faire une colonne lundi 07h, une autre lundi 08h,... dimanche 20h... lundi suivant 08h...
Puis une autre table avec la même chose pour le 2nd vélo etc
Ca me fait un nombre impressionnant de colonne et je pense que ce n'est pas la bonne méthode mais je ne vois pas comment faire de manière plus optimale (je ne m'y connais pas trop en BDD).

Une autre solution serait de faire une table par velo mais avec une colonne utilisateur et une colonne heure - mais au niveau de la requête SQL ca va être plus compliqué pour voir si un créneau est libre. Pour voir si un créneau est libre je suis obligé de récupérer tous les créneaux pour un velo donné et voir si celui que je cherche est libre.

Comment est ce que vous organiseriez la base de donnée pour optimiser cela ?

merci
23/07/2018, 19h01
fsmrel

Bonsoir droledenm,

Citation:

Envoyé par droledenm

je vois bien 1 table par vélo (V1, V2, V3,...)

Houlà ! C’est comme si une banque prévoyait une table par client !

Envisagez une table des vélos, et une ligne de la table par vélo.

Citation:

Envoyé par droledenm

et pour chaque velo une colonne 07h - 08h - 09h -... 20h que je remplis avec le nom de l'utilisateur.

Envisagez une table des réservations et une table des utilisateurs.

Les réservations ont une date/heure de début et une de fin, tout ça étant du type timestamp (date/heure).

Au niveau conceptuel (MCD) :

https://www.fsmwarden.com/developpez..._velos_mcd.png

Au niveau logique (MLD) :

https://www.fsmwarden.com/developpez..._velos_mld.png

Autrement dit, commencez de préférence par apprendre à modéliser, voyez par exemple l’ouvrage de Michel Diviné, Parlez-vous Merise ?
23/07/2018, 19h06
escartefigue

Et si on remettait les pièces du puzzle dans l'ordre

Citation:

Envoyé par droledenm

J'ai un site (Wordpress) pour de la location de velo.
Sur mon hébergeur, je peux mettre PHPMyAdmin et sur une base MySQL je veux mettre ma réservation de vélo.
Pour ca, je vois bien 1 table par vélo (V1, V2, V3,...) et pour chaque velo une colonne 07h - 08h - 09h -... 20h que je remplis avec le nom de l'utilisateur

Là, vous décrivez le "COMMENT" : nombre de tables, de colonnes...
Il faut d'abord s'intéresser au "QUI" et au QUOI et pour pouvoir le faire, il faut identifier les acteurs (les vélos, les plages horaires, les clients, les réservations...) puis s'intéresser aux règles de gestion, ces deux étapes sont incontournables

Exemple de règles de gestion (identifiées par un numéro pour faciliter les échanges) :
RG01 : pour une tranche horaire un vélo est réservé par au plus une personne
RG02 : pour une tranche horaire, une personne peut réserver plusieurs vélos
RG03 : ...

Citation:

Envoyé par droledenm

Je veux pouvoir réserver sur la semaine en cours et la semaine suivante ce qui m'oblige a faire une colonne lundi 07h, une autre lundi 08h,... dimanche 20h... lundi suivant 08h...
Puis une autre table avec la même chose pour le 2nd vélo etc
Ca me fait un nombre impressionnant de colonne et je pense que ce n'est pas la bonne méthode mais je ne vois pas comment faire de manière plus optimale (je ne m'y connais pas trop en BDD).

C'est effectivement exactement ce qu'il ne faut pas faire, mais nous éviterons facilement cet écueil si les acteurs et les règles de gestion sont clairement définies

Citation:

Envoyé par droledenm

Une autre solution serait de faire une table par velo mais avec une colonne utilisateur et une colonne heure - mais au niveau de la requête SQL ca va être plus compliqué pour voir si un créneau est libre. Pour voir si un créneau est libre je suis obligé de récupérer tous les créneaux pour un velo donné et voir si celui que je cherche est libre.

Ouh la la, surtout pas :aie:, même réponse que précédemment :)
25/07/2018, 08h11
droledenm

Merci,

@fsmrel, à quoi sert reservationId si j'ai réservation début et reservation fin ?
25/07/2018, 21h03
fsmrel

Bonsoir droledenm,

Citation:

à quoi sert reservationId si j'ai réservation début et reservation fin ?

L’attribut reservationId intervient dans l’identification obligatoire de l’entité-type RESERVATION. Je rappelle qu’un identifiant est artificiel, non porteur de sémantique. Il en va ainsi de l’identifiant {veloId} de l’entité-type VELO et de l’identifiant {veloId, reservationId} de l’entité-type RESERVATION. Pour cette entité-type, on aurait pu se contenter d’un identifiant {reservationId}, mais on marque le coup en y faisant intervenir veloId, dans la mesure où RESERVATION n’est jamais qu’une propriété multivaluée de VELO, donnant lieu à une entité-type faible (weak entity), non autonome, dont l’existence dépend strictement de celle de VELO. Dans le MCD que j’ai proposé, la mise entre parenthèses de la cardinalité 1,1 symbolise tout cela. C’est l’AGL (en l’occurrence PowerAMC) qui demande que l’on utilise ces parenthèses pour signifier que RESERVATION est une entité-type faible, et en l’occurrence on parle d’identification relative. Les autres AGL utilisent d’autres mickeys : soulignement de la cardinalité 1,1 avec Open ModelSphere (1,1), ajout de la lette R avec WinDesign (1,1 (R)), chevrons avec JMerise (<1,1>), etc.

Au niveau du MLD et du code SQL, en théorie vous pourriez vous dispenser de l’attribut reservationId et considérer la paire {veloId, reservationDebut} comme clé primaire de la table RESERVATION, mais il y a un risque, car il faut interdire le chevauchement des périodes de location et MySQL (disons version 5.7, au-delà je n’ai pas vérifié) ne propose strictement rien à ce sujet. De toutes façons, vous ne couperez pas à la mise en place de triggers (un pour les inserts et un pour les updates), pour interdire les chevauchements, mais évitez d’impliquer la clé primaire dans cette affaire ! Si vous utilisiez PostgreSQL, on pourrait reconsidérer la participation de la période de location à la clé primaire de RESERVATION, avec la mise en oeuvre du type INTERVAL (voyez ici et/ou EXTENSION btree_gist, voyez la doc PostgreSQL, où il est montré comment interdire que deux salles de cours soient réservées en même temps).