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

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:

Entreprise a les 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
)

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).

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

  • Pourquoi avez-vous besoin d'une M-à-M de la relation entre la business_hours table et les entreprises table? Si vous vraiment l'intention de faire plusieurs entreprises partagent le même enregistrement dans business_hours, pourquoi? Du point de vue sémantique, le fait que "la société C œuvres de T1 à T2 sur le jour J" est plutôt une valeur de l'objet à celle de l'entité... La seule bonne (?) raison pour laquelle je peux imaginer l'entreposage, optimisation de la taille du RDB (version de Mouche motif, façon de parler) si le nombre d'entreprises devrait être énorme...
  • Ce sujet de la pause déjeuner? Quid des jours fériés?
InformationsquelleAutor user128000 | 2009-06-24
  1. 50

    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 "heures de travail". (Au moins parce que 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.

    • Comment feriez-vous 2? Avoir toutes les entrées pour toutes les entreprises, même lorsque le jour/la même heure?
    • Je dirais que oui. Sinon, pensez à ce qui se passerait si les deux entreprises partagent le même nombre d'heures, mais ensuite, l'un d'eux a besoin de changer leurs heures. Vous devez détecter le fait que les horaires sont modifiés, et de créer un nouveau dossier, ou de modifier l'existant, selon que ses partagé ou non.
    • Je suis absolument ne serait pas partager les lignes de ce tableau entre les entreprises. Ce genre de partage juste conduit à la douleur. La logique métier de l'application doit juste respecter la contrainte que chaque entreprise a au moins 7 "business_hours" références.
    • Rappelez-vous que tout le valeurs sont (actuellement) de même, les heures d'ouverture pour les deux entreprises sont sémantiquement distinctes.
    • Vous pouvez également utiliser une image de 7 bits pour le champ "jour". De cette façon, vous n'avez pas à répéter les mêmes entrées Exemple tous les jours de travail ont les mêmes heures de travail, une entrée est assez.
    • que penser d'un restaurant avec l'ouverture de près de plus de un pour chaque jour.. e.g lundi 10h - 2pm et lundi 5 h - 10 h (il s'ouvre pendant le déjeuner et le dîner uniquement) . comment votre schéma de base de données permettra de soutenir cela ? comment pouvons-nous créer un tel flexible structure de données dans la base de données?
    • comment à propos du remplacement de open_time et close_time avec am_hours et pm_hours ses am_hours valeur sera une série comme 10:00-14:00 et pm_hours sera 17:00-22:00 ?
    • Regarde schema.org/OpeningHoursSpecification serait le meilleur. Ils comprennent une validFrom et validThrough date, ce qui est très courant pour les entreprises ou les magasins qui ont été et d'hiver, les heures d'ouverture

    InformationsquelleAutor Frank Krueger
  2. 22

    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 point, 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 voulez tester.

    • Qui est le meilleur moyen pour enregistrer ce genre de périodes d'ouverture ? Toute suggestion ?
    • C'est ce que je suis venu ici pour. Va essayer une solution qui permet d'économiser de l'ouvrir et de fermer la fois comme des entités distinctes, et, ensuite, de déterminer si une entreprise est "ouvert" par la recherche à tout changement qui aurait eu lieu plus récemment. Pensées?
    • Je suis lso interestered en faisant cela. Comment avez-vous finir de mettre en place?
    • J'ai fini par faire quelque chose comme @JordanFeldstein suggéré. Je stocker des tableaux de "changement d'état", qui incluent le changement (ouvrir ou fermer), le jour de la semaine et l'heure de la journée. Je peux avoir autant de "changements" que je veux pour chaque entreprise et chaque jour. Une entreprise peut ouvrir un jour et fermer l'autre, ouvrir deux fois (ou x fois) par jour, ouvert 24 heures, mais fermé le lundi, peu importe. C'est difficile à mettre en œuvre, mais très souple.
    • À la suite de la réponse la meilleure approche, je préfère ajouter deux colonnes à la business_hours: break_time et break_duration. Il est vraiment rare d'avoir 2 pauses dans la même journée.
    InformationsquelleAutor davidsheldon
  3. 10

    Ç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.
    • Un 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é.
    InformationsquelleAutor Frans
  4. 9

    J'ai appris que si vous voulez avoir des données de google balisage reconnaître vos données, vous devez suivre ces lignes directrices:

    https://schema.org/openingHours

    http://schema.org/OpeningHoursSpecification Contient des "dates de validité", ce qui est très utile pour certaines entreprises.

    https://schema.org/docs/search_results.html#q=hours

    Vous devriez être très bien sans une clé primaire, sauf si vous êtes en permettant aux entreprises de partager les mêmes heures avec la table de jointure - il est intéressant de noter que finalement vous aurait un nombre fini de combinaisons; je ne suis pas sûr de savoir comment beaucoup de qui serait :p

    Avec l'un de mes projets, j'ai utilisé les colonnes:

    [uInt]business_id, [uTinyInt jour], [char(11)]timeRange

    Si vous voulez soutenir OpeningHoursSpecification alors vous aurez besoin d'ajouter validFrom et validThrough.

    Intervalle de temps est formaté comme: hh:mm-hh:mm

    Voici une fonction qui analyse,
    vous pouvez également modifier cette fonction pour analyser un seul ouvrir/fermer, si vous les garder comme des colonnes distinctes dans la base de données.

    De mon expérience, je vous recommande d'autoriser plusieurs fois dans un jour, permettre une façon de dire si elles sont explicitement fermé ce jour-là, ouvert 24 heures ou 24/7.
    J'ai eu la mienne dire que si il y avait un jour manquantes dans la base de données puis l'entreprise a été fermée ce jour-là.

    /**
 * parseTimeRange
 * parses a time range in the form of
 * '08:55-22:00'
 * @param $timeRange 'hh:mm-hh:mm' '08:55-22:00'
 * @return mixed ['hourStart'=>, 'minuteStart'=>, 'hourEnd'=>, 'minuteEnd'=>]
 */
function parseTimeRange($timeRange)
{
    //no validating just parsing
    preg_match('/(?P<hourStart>\d{1,2}):(?P<minuteStart>\d{2})-(?P<hourEnd>\d{1,2}):(?P<minuteEnd>\d{2})/', $timeRange, $matches);

    return $matches;
}
    InformationsquelleAutor CTS_AE
  5. 0

    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.

    InformationsquelleAutor Einstein