Conception de database pour la disponibilité d'une personne

Je travaille actuellement sur une application web qui stocke les informations des cuisiniers dans la table des users. Nous avons une fonctionnalité pour searchr les cuisiniers à partir de notre application web. Si un cuisinier n'est pas disponible le 3 mai 2016, nous souhaitons afficher le message Not-Available ou Not-Available pour ce cuisinier si l'user effectue la search le 3 mai 2016. La solution que nous avons trouvée est de créer un table nommée CooksAvailability avec les champs suivants

 ID, //Primary key, auto increment IDCook, //foreign key to user's table Date, //date he is available on AvailableForBreakFast, //bool field AvailableForLunch, //bool field AvailableForDinner, //book field BreakFastCookingPrice, //decimal nullable LunchCookingPrice, //decimal nullable DinnerCookingPrice //decimal nullable

Avec ce schéma, nous sums en mesure de dire si l'user est disponible pour une date spécifique ou non. Mais le problème avec cette approche est qu'elle nécessite beaucoup d'espace db, donc si un cuisinier est disponible pendant 280 jours / an, il doit y avoir 280 lignes pour refléter la disponibilité d'un seul cuisinier.

C'est trop d'espace count tenu du fait que nous pourrions avoir potentiellement des milliers de cuisiniers enregistrés avec notre application. Comme vous pouvez voir les champs CookingPrice pour le petit déjeuner, le déjeuner et le dîner. Cela signifie qu'un cuisinier peut facturer différents taux de cuisson pour cuisiner à différentes dates et heures.

Actuellement, nous recherchons une solution intelligente qui répond à nos besoins et consum less d'espace que notre solution.

Vous stockez un logging pour chaque jour et l'erreur principale, qui vous a conduit à cette design redondante était que vous n'avez pas assez séparé les concepts.

Je ne sais pas si un cuisinier a un taux prévu pour un repas donné, c'est-à-dire un prix que l'on peut supposer en général si l'on n'a pas d'informations supplémentaires. Si tel est le cas, vous pouvez stocker ces prix par défaut dans la table où vous stockez les cuisiniers.

Stockons la disponibilité et les prix spécifiques dans différentes tables. Si la disponibilité ne doit pas stocker les prix, vous pouvez stocker les intervalles de disponibilité. Dans l'autre tableau, où vous stockez les prix, vous devez stocker uniquement les prix qui s'écartent du prix attendu. Ainsi, vous aurez défini des intervalles de disponibilité dans un tableau, des prix spécifiques lorsque le prix diffère de celui attendu dans les autres valeurs de prix repas dans la table de cuisson, donc, s'il n'y a pas de prix spécial, le prix par défaut sera utilisé .

Pour répondre à votre question, je devrais en savoir plus sur la structure de l'information. Par exemple, si la plupart des cuisiniers sont disponibles pendant une certaine période, il pourrait être utile d'organiser votre table de disponibilité avec

avail_from_date – avail_to_date, au lieu d'une ligne pour chaque jour.

cela réduirait la quantité de lignes.

Les différents prix pour le petit-déjeuner, le déjeuner et le dîner pourraient être mieux stockés dans la table des cuisiniers, si les prix ne sont pas différents chaque jour. Idem pour la disponibilité pour le petit déjeuner, le déjeuner et le dîner si ce n'est pas différent chaque jour.

Mais si votre structure d'information oblige à garder un record pour chaque cuisinier tous les jours ce serait 365 * 280 = 102 200 loggings par an, ce n'est pas beaucoup pour une db sql à mes yeux. Si vous placez les index au bon endroit, les performances seront bonnes.

Il y a quelques questions qui pourraient aider avec la réponse globale.

À quelle fréquence la disponibilité change-t-elle?
À quelle fréquence le prix change-t-il?
Existe-t-il des templates généraux, par exemple le cuisinier X est disponible pour le petit-déjeuner et le déjeuner, du lundi au mercredi chaque semaine?
Y a-t-il un rapport disponibilité / prix normal sur une certaine période de time, mais avec des dérogations / différences à court terme?

Si la disponibilité et le prix changent à des vitesses différentes, je vous suggère de les modéliser séparément. De cette façon, vous avez seulement besoin de montrer ce qui a changé, plutôt que de dupliquer des données qui sont constantes.

Au-delà, il y a un compromis espace / complexité à faire.

À un extrême, vous pourriez avoir une hiérarchie de configurations qui se chevauchent. Donc, pour le cuisinier X, il y a l'set A qui dit qu'ils peuvent faire le petit déjeuner du lundi au mercredi entre les dates 1 et 2. Pour le cuisinier X, il y a l'set B qui dit qu'ils peuvent déjeuner le jeudi entre les dates 3 et 4. -> 3 -> 4 -> 2, vous pouvez définir si l'set B remplace A ou lui ajoute. C'est le plus concis, mais il y a beaucoup de logique métier à interpréter.

A l'autre extrême, vous dites juste pour le cuisinier X entre la date 1 et 2 cette chose est vraie (une disponibilité pour un service, un prix). Vous trouvez toutes les choses qui sont vraies pour une date donnée, en apportant éventuellement plusieurs loggings séparés, par exemple une disponibilité pour le déjeuner du lundi, un prix du déjeuner pour le lundi, etc.