Stocker des Heures de travail dans une Base de données

Question

Je suis en train d'essayer de travailler sur la meilleure façon de stocker une entreprise d'heures de fonctionnement dans une base de données.

Par exemple:

Entreprises Une a la suite des heures de fonctionnement

• Lundi: 9am - 5pm
• Mardi: 9am - 5pm
• Mercredi: 9am - 5pm
• Jeudi: 9am - 5pm
• Vendredi: 9am - 5pm
• Samedi: 9 h - 12 h
• Dimanche: Fermé

Actuellement, je suis un modèle de données semblable à la suivante

CREATE TABLE "business_hours" (
    "id" integer NOT NULL PRIMARY KEY,
    "day" varchar(16) NOT NULL,
    "open_time" time,
    "close_time" time
)

d'où le "jour" est limité à un choix de 7 jours de la semaine dans le code (par le biais de l'ORM). Pour tester si une entreprise est fermée sur un certain jour, il vérifie si le open_time et close_time sont NULLES. Il est lié à l'entreprise par le biais d'un intermédiaire de table (plusieurs-À-Plusieurs Relation).

Quelqu'un a des suggestions pour cette base de données? Quelque chose ne semble pas juste pour moi.

Answer 1

Dans l'ensemble, je ne vois rien de mal avec cela. Sauf que...

1. Je voudrais stocker le jour de la semaine comme un entier à l'aide de quelque système de numérotation de votre propre langage de programmation utilise (dans ses bibliothèques). Cela permettra de diminuer la taille de la base de données et supprimer les comparaisons de chaînes à partir de votre code.

2. Je serais probablement mis la clé étrangère de la table métier, ici, dans ce tableau. De cette façon, vous n'aurez pas besoin d'une table de lien.

Donc je suppose que je ferais:

CREATE TABLE "business_hours" (
     "id" integer NOT NULL PRIMARY KEY,
     "business_id" integer NOT NULL FOREIGN KEY REFERENCES "businesses",
     "day" integer NOT NULL,
     "open_time" time,
     "close_time" time
)

Dans ma logique d'entreprise, je voudrais appliquer une contrainte que tous les "affaires" a au moins 7 des "heures de travail". (Au moins , car Jon Skeet est juste, vous pourriez vouloir les heures de vacances.) Si vous souhaitez vous relaxer cette contrainte, simplement en laissant des "heures de travail" pour les jours que l'entreprise est fermée.

Answer 2

Une situation qui n'est pas couverte par le présent schéma est plusieurs périodes d'ouverture dans une journée. Par exemple, le pub local est ouvert de 12:00-14:30 et 17:00 à 23:00.

Peut-être un théâtre de la billetterie est ouverte pour une matinée et une soirée de performances.

À ce stade, vous devez décider si vous pouvez avoir plusieurs entrées pour le même jour, ou si vous avez besoin de représenter des heures différentes dans la même ligne.

Ce que les horaires que de la croix de minuit. Dire un bar est ouvert de 19:00-02:00. Vous ne pouvez pas il suffit de comparer les horaires douverture et de fermeture avec le temps que vous souhaitez tester.

Answer 3

Ça dépend de ce que vous avez besoin de stocker et de quoi les données du monde réel pourrait ressembler.
Si vous avez besoin d'être en mesure de déterminer si l'entreprise est ouverte à un certain point, alors, il peut être un peu gênant pour interroger le régime comme prévu. Plus important encore, cependant, est: Serait jamais vous en avez besoin pour répondre à la mi-journée de fermeture?

Certaines options comprennent;

• Un modèle semblable à ce que vous avez, mais avec la possibilité d'avoir plusieurs périodes de la journée même. Elle permettrait de répondre à la pause de midi, mais le rendrait difficile à exécuter une requête qui vous donne les heures d'ouverture pour un jour donné, par exemple pour la présentation à un utilisateur.
• Une image bitmap approche de style; "000000000111111110000000" pour 9-5. L'inconvénient de cette approche est qu'il vous faudra choisir une granularité, c'est à dire toute les heures ou demi-heures, voire minutes. Le plus fin de granularité, plus les données sont à lire pour un humain. Vous pouvez utiliser les opérateurs sur les bits pour stocker cette valeur comme un numéro unique plutôt qu'une chaîne de nombres entiers, mais encore une fois ça fait mal à la lisibilité.

Answer 4

Pourrait penser à la prise en compte des jours fériés en incluant des champs supplémentaires pour les mois de l'année, du jour de mois/semaine du mois. Semaine de mois a quelques petites subtlties "dernier" pourrait par exemple être la semaine 4 ou 5 en fonction de l'année.