Discussion :

[noname2]

Bonjour à tous,

J'espère être dans la bonne section. Je suis novice en sql. J’ai un projet à réaliser comportant beaucoup de données et je suis un peu dépassé . Je me permets de venir vers vous pour quelques conseils..

Il s’agit de réservation en ligne de chambres d’hôtels.

Il faut compter environ 150 chambres référencées sur le site dans un premier temps.

Chacune de ces chambres comporte plusieurs caractéristiques comme leur situation géographique en France, le type de chambre dont il s’agit, la vue etc.

Les internautes devront pouvoir effectuer des recherches de chambre, leurs critères (en dehors des caractéristiques énoncés plus haut) seront également la date de disponibilité et le prix maximum.

Les propriétaires des chambres, eux, pourront ajuster leurs tarifs à leur convenance en fonction des dates via un outil d’administration. En gros, ils auront accès à un calendrier correspondant à chaque chambre et à chaque nuit correspondra un prix potentiellement différent.

Du coup, hormis une première table chambres dont chaque nouvelle entrée serait une nouvelle chambre et qui référencerait les caractéristiques fixes comme le type de chambre, la situation géographique etc. je pensais créer une table calendrier par chambre (calendrierChambre1, calendrierChambre2, calendrierChambre3 etc.). Dans ces tables calendrier figurerait les jours des 5 prochaines années en tant qu’id unique des différentes entrées, et comme autre champs : tarif (avec le tarif du jour), resa (avec un id de réservation si la chambre n’est plus libre), puis une table référençant toutes les réservations.

Ce qui m’inquiète, c’est la requête côté internaute, car celle-ci va devoir se faire sur 150 tables différentes (dans un premier temps), comportant chacune 1825 entrées (365 jours x 5 ans). En même temps, si je décide de ne faire qu’une table référençant toutes les dates, je vais devoir fouiller dans un nombre incalculable d’entrées, ce qui me parait être de la folie aussi… Sinon, j’avais pensé placer un tableau dans un champ dates de ma table chambres dans lequel j’aurais placé la même chose que dans mes différentes tables calendrier (j’aurais ainsi eu une unique table mais avec une troisième dimension). Le problème c’est qu’avec une requête sql je ne peux pas lire à l’intérieur d’un tableau…

Qu’en pensez-vous ? Est-ce qu’il y a beaucoup plus simple et que je m’y prends mal ? Est-ce juste un gros projet et difficile de faire autrement ?

Merci par avance pour vos avis !

[CinePhil]

Il faut compter environ 150 chambres référencées sur le site dans un premier temps.

...

je pensais créer une table calendrier par chambre (calendrierChambre1, calendrierChambre2, calendrierChambre3 etc.).

Non, une seule table calendrier avec une clé étrangère référençant les chambres.

Qu’en pensez-vous ? Est-ce qu’il y a beaucoup plus simple et que je m’y prends mal ?

Ma première réponse indique que tu t'y prends mal.

Tu devrais prendre un peu de Merise et chercher dans ce forum, il y a déjà eu des sujets similaires (mots clés : réservation chambres, hôtel...).

[ericd69]

salut,

cinephil a raison tu peux faire en gros 3 tables pour gérer le tout:

• une table chambres qui contient leur caractéristiques
• une table reservations avec pour clé étrangère l'id des chambres que rempliront donc les clients
• une table prix avec pour clé étrangère l'id des chambres que rempliront tes propriétaires pour fixer les périodes avec les différents coûts
• une table propriétaires qui permettra de les identifier (mdp,adresse, tel, etc...)

vu que c'est pour une application à priori professionnelle je te conseille un moteur de table innodb pour gérer de manière un peu plus sure les risques de plantage des transaction et en plus ça gérera réellement les clé étrangère si tu les déclares dans la syntaxe de ta table et les éventuelle cascades de delete...

dans les caractéristiques de base je te conseille de mettre une colonne "prix-defaut" qui fixera le prix hors des périodes avec prix particuliers ou alors tu pars du principe que s'il n'y a pas de prix sur une période c'est que la chambre n'est pas louable... de même, faut penser au recouvrement des période possible la gestion des choses... est ce que tu l'autoriseras ou tu le réguleras pour l'empêcher?

perso je suis très sql procédural car ça limite grandement les aller-retour php-mysql et ça introduit une plus grande facilité de maintenance et plus de sécurité...je te conseille ensuite de faire les procédures stockées suivantes:

• une qui permettra de tester les réservations et calculera le prix, la période de réservation réellement disponible, etc...
• une qui fera la réservation effectivement
• une qui listera les périodes tarifaires pour une chambre
• une qui modifiera les périodes tarifaires pour une chambre
• une qui permettra de tester l'identification d'un propriétaire

c'est pas exhaustif mais ça permet déjà de couvrir le gros des besoins et de faire des traitements conditionnel complexes... en plus, en terme de sécurité tu peux n'utiliser, coté php, qu'un utilisateur mysql ayant seulement le droit "execute" ce qui limite tout un tas d'attaques par injections et j'en passe et des meilleures...


bref à toi de voir ce qui te convient le mieux mais quoiqu'il en soit avant de te lancer va vraiment falloir que tu pense bien à tout ce qui est gestion des périodes sur les réservations et les prix pour éviter les gros loupés...

courage