J'ai un problème intéressant qui tente de représenter des données de planification complexes dans une base de données. En tant que directive, je dois être en mesure de représenter l'intégralité de ce que le format iCalendar - J'ai besoin d'autoriser une représentation d'un seul événement ou d'un événement récurrent basé sur plusieurs fois par jour, jours de la semaine, semaine d'un mois, mois, année ou une combinaison de ceux-ci. Par exemple, le troisième jeudi de novembre annuellement, ou le 25 décembre annuel, ou toutes les deux semaines à compter du 2 novembre et se poursuivant jusqu'au 8 septembre l'année suivante.
Je m'en fiche de l'efficacité d'insertion, mais l'efficacité de la requête est essentielle. L'opération que je ferai le plus souvent fournit une seule date / heure ou une plage de date / heure et d'essayer de déterminer si la planification définie correspond à n'importe quelle partie de la plage de date / heure. D'autres opérations peuvent être plus lentes. Par exemple, compte tenu du 15 janvier 2010 à 10h00 jusqu'au 15 janvier 2010 à 11h00, trouvez tous les horaires correspondant au moins une partie de cette époque. (C'est-à-dire un horaire qui couvre 10h30 - 11h00 correspond toujours.)
Toute suggestion? J'ai regardé Comment fonctionnerait-il des événements planifiés dans un SGBDM? < / a> Mais cela ne couvre pas la portée du type de règles de récurrence que je voudrais modéliser. ics peut représenter, mais dans une base de données. Je ne mettant rien en train de mettre en œuvre quelque chose concernant ics , mais cela donne une bonne portée du type de règles que je dois pouvoir modéliser mon projet particulier.
3 Réponses :
La façon dont j'ai fait quelque chose de similaire à cela devait avoir deux tables. Si un événement n'avait pas de motif récurrent, puis stockez simplement la date, l'heure de début et l'heure de fin. Votre requête vérifie si l'heure de votre recherche est supérieure à la durée de début de toute entrée et inférieure ou égale à la fin de cette même épreuve.
Pour les événements récurrents, je ne suis pas trop familier avec la récidive des magasins iCalendar, mais si vous stockez chaque événement au jour de la semaine (vous devrez peut-être avoir plusieurs lignes pour un seul événement s'il répète plus d'un jour Une semaine), puis cherchez-la presque la même chose que la table ci-dessus. Pour des récurrences étrangères comme le troisième mardi de la semaine, vous pourriez avoir une colonne supplémentaire décrivant la condition spécifique. Je pourrais peut-être vous donner une meilleure réponse pour cela si vous pouviez me dire plus sur la manière dont les ICS représentent ce type de récurrence.
J'espère que cela aide. Je n'ai pas beaucoup de temps en ce moment. Vous pouvez me contacter plus tard si vous voulez en discuter. Je suis actuellement dans le Missouri, alors ma disponibilité pour la semaine prochaine sera erratique.
Cela pourrait être une solution triviale, mais quels seraient les inconvénients de l'ajout d'une colonne qui définit la récurrence de l'événement (c'est-à-dire chaque x semaines, chaque année, hebdomadaire, etc.) et en utilisant cela comme le critère de résultat?
En fin de compte, ce message était le plus utile:
liste "Champ" (pour le schéma de base de données Basé sur la norme ICAL)
Nous avons décidé de suivre le modèle ICAL joli exactement depuis que les gars qui ont écrit que la norme avait une grande conviction pour le domaine problématique.