Structure des données du calendrier

Question

Nous cherchons à mettre à jour (réécrire) notre système qui stocke des informations sur quand les gens peuvent réserver des chambres etc. pendant la journée. À l'heure actuelle, nous stockons le début et l'heure et la date à laquelle la salle est disponible dans une table, et dans un autre, nous stockons les heures de rendez-vous individuels. En apparence, il semblait logique de stocker les informations de cette façon, mais avec le temps et le système a été soumis à de lourdes charges, nous avons commencé à réaliser que cette structure de données semblait inefficace. (Cela devient une opération intensive de chercher dans toutes les salles les heures disponibles et de calculer quand les salles sont disponibles.Si la salle est disponible pour une période donnée, est-ce que le temps est disponible assez longtemps pour accommoder l'heure demandée).

Nous avons tourné en rond sur la façon de rendre le système plus efficace, et nous pensons qu'il doit y avoir une meilleure façon d'aborder cela. Est-ce que quelqu'un a des suggestions sur la façon de s'y prendre, ou a des endroits où chercher comment construire quelque chose comme ça?

Answer 1

Je trouve ce livre à être source d'inspiration et un incontournable pour tout type de base de données impliquant la gestion du temps/contraintes:

Developing Time-Oriented Database Applications in SQL

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

Answer 2

@ Radu094 vous a indiqué une bonne source d'information - mais il sera difficile de traiter cela. À un niveau horriblement pragmatique, avez-vous envisagé d'enregistrer les rendez-vous et les informations disponibles dans une seule table plutôt que dans deux tables? Pour chaque jour, découpez le temps en «jamais disponible» (avant l'ouverture du bureau, après la fermeture du bureau - si une telle chose se produit), «disponible - peut être alloué» et «non disponible». Ces (deux ou) trois classes de réservations seraient enregistrées dans des intervalles contigus (avec des heures de début et de fin pour chaque intervalle dans un seul enregistrement).

Pour chaque salle et chaque date, il est nécessaire de créer un ensemble de réservations «inutilisées» (selon que vous utilisez «jamais disponible», l'ensemble peut être un enregistrement «disponible» ou il peut inclure le décalage anticipé et le décalage tardif des enregistrements «jamais disponibles» aussi).

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

• Puis-je réserver la salle X le jour Y entre T1 et T2?
• Y at-il de la place disponible le jour Y entre T1 et T2?
• À quels moments le jour Y est-il encore disponible?
• A quelle heure le jour Y est une salle avec des capacités audiovisuelles et une capacité de 12 personnes?
• À qui la salle X a-t-elle réservé le matin du jour Y?

Ceci est seulement un petit sous-ensemble des possibilités. Mais avec un peu de soin et d'attention aux détails, les requêtes deviennent gérables. La validation des contraintes dans le SGBD sera plus difficile. C'est-à-dire, s'assurer que si l'heure [T1..T2] est réservée, alors personne d'autre ne consigne [T1 + 00: 01..T2-00: 01] ou toute autre période de chevauchement. Voir Allen's Interval Algebra sur Wikipedia et d'autres lieux (y compris celui-ci au uci.edu).