Mysql
 sql >> Base de données >  >> RDS >> Mysql

Conception de la base de données des règles de prix pour le système de réservation d'hôtel

J'ai en fait travaillé sur la conception et la mise en œuvre d'un système de réservation d'hôtel et je peux offrir les conseils suivants basés sur mon expérience.

Je recommanderais votre deuxième option de conception, en stockant un enregistrement pour chaque combinaison Date / Hôtel. La raison en est que, bien qu'il y ait des périodes où le tarif d'un hôtel est le même sur plusieurs jours, il est plus probable que, selon la disponibilité, il changera avec le temps et deviendra différent (les hôtels ont tendance à augmenter le prix de la chambre à mesure que la disponibilité diminue).

Il existe également d'autres informations importantes qui devront être stockées et spécifiques à un jour donné :

  1. Vous devrez gérer la disponibilité de l'hôtel, c'est-à-dire à la Date x il y a y chambres disponibles. Cela variera presque certainement selon le jour.
  2. Certains hôtels ont des périodes d'interdiction pendant lesquelles l'hôtel n'est pas disponible pendant de courtes périodes (généralement des jours spécifiques).
  3. Délai :certains hôtels n'autorisent la réservation des chambres qu'un certain nombre de jours à l'avance. Cela peut varier entre les jours de la semaine et les week-ends.
  4. Nuits minimales, encore une fois des données stockées par date individuelle qui indiquent que si vous arrivez ce jour-là, vous devez rester x nombre de nuits (disons sur un week-end)

Considérez également une personne réservant un séjour d'une semaine, la requête de base de données pour renvoyer les tarifs et la disponibilité pour chaque jour de ce séjour est beaucoup plus concise si vous avez un enregistrement de prix pour chaque date. Vous pouvez simplement faire une requête où la date du tarif de la chambre est ENTRE la date d'arrivée et la date de départ pour renvoyer un ensemble de données avec un enregistrement par date du séjour.

Je me rends compte qu'avec cette approche, vous stockerez plus d'enregistrements, mais avec des tables bien indexées, les performances seront bonnes et la gestion des données sera beaucoup plus simple. A en juger par votre commentaire, vous ne parlez que d'environ 18 000 enregistrements, ce qui est un volume assez petit (le système sur lequel j'ai travaillé en a plusieurs millions et fonctionne bien).

Pour illustrer la gestion supplémentaire des données si vous NE PAS stockez un enregistrement par jour, imaginez qu'un hôtel a un tarif de 100 USD et 20 chambres disponibles pour tout le mois de décembre :

Vous commencerez avec un enregistrement :

1-Dec to 31st Dec Rate 100 Availability 20

Ensuite, vous vendez une chambre le 10 décembre.

Votre logique métier doit maintenant créer trois enregistrements à partir de celui ci-dessus :

1-Dec to 9th Dec Rate 100 Availability 20 10-Dec to 10th Dec Rate 100 Availability 19 11-Dec to 31st Dec Rate 100 Availability 20

Ensuite, le taux passe les 3 et 25 décembre à 110

Votre logique métier doit maintenant diviser à nouveau les données :

1-Dec to 2-Dec Rate 100 Availability 20 3-Dec to 3-Dec Rate 110 Availability 20 4-Dec to 9-Dec Rate 100 Availability 20 10-Dec to 10-Dec Rate 100 Availability 19 11-Dec to 24-Dec Rate 100 Availability 20 25-Dec to 25-Dec Rate 110 Availability 20 26-Dec to 31-Dec Rate 100 Availability 20

C'est plus de logique métier et plus de frais généraux que de stocker un enregistrement par date.

Je peux vous garantir qu'au moment où vous aurez terminé, votre système se retrouvera de toute façon avec une ligne par date. Vous pouvez donc aussi bien le concevoir de cette façon dès le début et bénéficier des avantages d'une gestion des données plus facile et de requêtes de base de données plus rapides.