Structure de données du calendrier horaire

Question

Nous envisageons de mettre à jour (réécrire) notre système, qui stocke des informations sur le moment où les personnes peuvent réserver des chambres, etc. pendant la journée. Actuellement, nous stockons le début, l'heure et la date à laquelle la salle est disponible dans une table, et dans une autre, nous stockons les heures de rendez-vous individuels.

Au premier abord, il semblait logique de stocker les informations de cette façon, mais avec le temps et le système étant très chargé, nous avons commencé à nous rendre compte que cette structure de données semblait inefficace. (Cela devient une opération intensive de rechercher toutes les chambres pour les heures disponibles et de calculer quand les chambres sont disponibles. Si la chambre est disponible pour une heure donnée, est-il le temps qu'il est disponible assez longtemps pour accueillir l'heure demandée).

Nous avons fait le tour de la question pour rendre le système plus efficace et nous pensons qu’il doit exister une meilleure façon de procéder. Quelqu'un a-t-il des suggestions sur la façon de s'y prendre, ou a-t-il des endroits où regarder pour construire quelque chose comme ça?

Answer 1

J'ai trouvé ce livre inspirant et incontournable pour tout type de base de données impliquant une gestion du temps / des contraintes:

Développement d'applications de base de données orientées temps en SQL

( Ajouté par l'éditeur : le livre est disponible en ligne, via la page d'accueil de Richard Snodgrass . bon livre.)

Answer 2

@ Radu094 vous a indiqué une bonne source d’informations, mais le traitement sera difficile.

À un niveau horriblement pragmatique, avez-vous envisagé d’enregistrer les rendez-vous et les informations disponibles dans un seul tableau plutôt que dans deux tableaux? Pour chaque jour, divisez le temps en "jamais disponible" (avant l'ouverture du bureau, après la fermeture du bureau - le cas échéant), "disponible - peut être alloué" et "non disponible". Ces (deux ou trois) catégories de réservations seraient enregistrées à intervalles continus (avec les heures de début et de fin pour chaque intervalle d’un enregistrement).

Pour chaque salle et chaque date, il est nécessaire de créer un ensemble de réservations "inutilisées" (selon que vous choisissez l'option "jamais disponible", l'ensemble peut être un enregistrement "disponible" ou inclure le les enregistrements «jamais disponibles» trop tôt et plus tardivement.

Ensuite, vous devez déterminer quelles questions vous posez. Par exemple:

• Puis-je réserver la chambre X le jour Y entre le T1 et le T2?
• Y a-t-il une chambre disponible le jour Y entre le T1 et le T2?
• À quelles heures du jour Y la salle X est-elle encore disponible?
• À quelle heure le jour Y une salle avec des capacités audio-visuelles et une capacité de 12 personnes est-elle disponible?
• Qui a réservé la chambre X le matin du jour Y?

Ceci n'est qu'un petit sous-ensemble des possibilités. Mais avec un peu de soin et d’attention pour les détails, les requêtes deviennent gérables. La validation des contraintes dans le SGBD sera plus difficile. C’est-à-dire qu’il faut s’assurer que si le temps [T1..T2) est réservé, personne d’autre ne comptabilise [T1 + 00: 01..T2-00: 01] ou toute autre période de chevauchement. Voir Algèbre à intervalles d'Allen sur Wikipedia et autres lieux (y compris celui-ci sur uci.edu ).