2008-12-23 10 views
6

Actuellement, je travaille sur un projet de gestion des fenêtres de maintenance sur une base de données de serveurs, etc. Fondamentalement, je dois seulement être précis jusqu'à l'heure, mais permettre qu'ils soient réglés pour permettre, ou interdire, pour chaque jour de la semaine.Horaires hebdomadaires - Comment pouvez-vous stocker cela dans une base de données?

J'ai eu quelques idées sur la façon de faire cela, mais puisque je travaille par moi-même, je ne veux pas m'engager à quelque chose sans quelques commentaires.

Pour visualiser cela, il est quelque chose comme le « graphique » qui coule

| Sun | Mon | Tue | Wed | Thu | Fri | Sat | 
    ------------------------------------------- 
5AM |allow|allow|allow|deny |deny |allow|allow| 
    ------------------------------------------- 
6AM |allow|deny |deny |deny |deny |deny |allow| 
    ------------------------------------------- 
7AM |allow|deny |deny |deny |deny |deny |allow| 
    ------------------------------------------- 
8AM |allow|deny |deny |deny |deny |deny |allow| 
    ------------------------------------------- 
9AM |allow|deny |deny |deny |deny |deny |allow| 
    ------------------------------------------- 
... etc... 

est-il un moyen standard de faire ceci ou une ressource qui pourrait me donner quelques idées à ...

  1. Faire un format qui peut être sauvegardé et restauré facilement
  2. Faire consultable dans la base (par exemple, ne pas avoir à désérialiser pour rechercher un temps)

[Mise à jour]

Il convient de mentionner qu'un jour pourrait, même si peu probable, être réglé sur "allow, deny, allow, deny ... etc ...". La durée n'est pas garantie d'être le seul pour toute la journée.

Ce n'est pas non plus le seul emploi du temps, il y aura des centaines de dispositifs chacun avec leur propre horaire, donc ça va devenir poilu ... lol ??

Rob demandé si chaque semaine devait être suivie - Ce n'est pas le cas. Ceci est un programme générique qui s'appliquera à toute l'année (entretien régulier)

+0

Avez-vous besoin de suivre chaque semaine de l'année, ou est-ce juste une table de configuration pour une semaine générique? –

+0

Il me semble que vous avez besoin de faire pivoter cette table, car si vous voulez obtenir toutes les heures pour un certain jour, vous devez retourner 24 lignes avec un moyen facile de WHERE les données. Il me semble avoir 7 lignes avec 24 colonnes plus de sens, 1 ligne vous donne toutes les heures pour un jour donné. – TravisO

+0

Idée intéressante Travis – Hugoware

Répondre

0

Peut-être quelque chose comme

TABLE: 
    StartTime DATETIME  PrimaryKey, 
    EndTime DATETIME  PrimaryKey, /*if you are positive it will be in one hour incerments then you might want to omit this one*/ 
    Monday BIT, 
    TuesDay BIT, 
    Wednesday BIT, 
    Thursday BIT, 
    Friday BIT, 
    Saturday BIT, 
    Sunday BIT 
8

Je considérerais pour (1) en utilisant un format qui comprend à la fois de début et de fin, et un champ entier pour le jour de la semaine. Je sais que vous avez déclaré que les blocs seront toujours d'une heure, mais cela peut être imposé par votre code. En outre, si vos besoins changent un jour, vous aurez beaucoup moins à vous soucier de l'étape (2) que si vos instructions DB sont toutes écrites en supposant des blocs d'une heure.

CREATE TABLE maintWindow (
    maintWindowId int primary key auto_increment not null, 
    startTime  Time, 
    endTime  Time, 
    dayOfWeek  int, 
    ... 

Pour (2), si chaque enregistrement a un début et de fin qui lui est associée, il est très facile de vérifier les fenêtres pour un moment donné:

SELECT maintWindowId 
FROM maintWindow 
WHERE $time >= TIME(startTime) AND $time <= TIME(endTime) AND DAYOFWEEK($time) = dayOfWeek 

(où $time représente la date et heure que vous voulez vérifier).

L'autorisation ou l'interdiction pour chaque jour de la semaine serait traitée par des enregistrements distincts. À mon humble avis, cela est plus flexible que le codage dur pour chaque jour de la semaine, puisque vous utiliserez alors une sorte de déclaration de cas ou if-else pour vérifier la bonne colonne de DB pour le jour qui vous intéresse.

Remarque: Assurez-vous de connaître la norme utilisée par votre base de données pour le jour entier de la semaine et essayez de rendre votre code indépendant (demandez toujours la base de données). Nous avons eu beaucoup de plaisir avec différentes normes pour le début de la semaine (dimanche ou lundi) et l'indice de départ (0 ou 1).

+1

C'est certainement l'approche que j'utiliserais. –

1

Si cela doit être différent chaque semaine, configurez la table comme ceci;

TABLE: 
    StartTime DATETIME PrimaryKey 

Si une heure de début pour une date/heure particulière est définie, alors supposez qu'elle est autorisée, sinon refusez.

S'il s'agit d'une configuration générique pour une semaine générique qui ne change pas, essayez ceci;

TABLE: 
    Hour INT, 
    Day INT, 
    Allow BIT 

Ajoutez ensuite des lignes pour chaque combinaison heure/jour.

1

J'ai déjà utilisé cette conception auparavant, en créant un bitmap pour l'intervalle de temps que vous souhaitez planifier régulièrement divisé par le nombre de périodes que vous souhaitez. Donc, dans votre exemple, vous voulez un horaire hebdomadaire avec des périodes horaires, donc vous aurez un bitmap de 168 bits qui n'a que 21 octets de long. Quelques dattes ont 16 octets ensemble et vous aurez besoin de plusieurs rangées pour représenter les horaires possibles pour une semaine donnée, donc si vous vous souciez de la taille, je ne pense pas que vous puissiez la battre.

Je reconnais que c'est un peu plus délicat à gérer et moins flexible que les suggestions précédentes. Considérez si vous avez tout d'un coup voulu utiliser des périodes de 1/2 heure, vous auriez besoin de transcoder toutes vos données existantes à un nouveau bitmap de 336 bits et de distribuer des valeurs. Si vous utilisez SQL, vous pouvez le stocker en tant que blog binaire et faire le twittling bit pour comparer si un bit est activé ou désactivé vous-même ou vous pouvez stocker chaque bit en tant que colonne. MS SQL Server prend en charge jusqu'à 1024 pour les tables standard ou 30k pour les tables larges, ce qui vous permet d'obtenir une granularité allant jusqu'à 10 minutes pour l'une ou l'autre, ou bien pour une table de 30 Ko. J'espère que cela ajoute un peu de perspective différente sur la façon dont cela pourrait être fait. Ce n'est vraiment nécessaire que si vous êtes préoccupé par l'espace/taille ou si vous avez peut-être 10 ou 100 millions de personnes.

1

Vous pouvez facilement enregistrer les heures "autorisées" dans un tableau. De cette façon, si ce n'est pas là, ce n'est pas autorisé. Si vous avez besoin d'un "calendrier" plus variable, vous pouvez facilement ajouter un champ d'année et de mois.

TABLE DBMaintSched 
     ID int PK 
     ServerID varchar(30) (indexed) 
     Day int 
     Month char(3) 
     DayOfWeek char(3) 
     Year int 
     StartDT DateTime 
     EndDT DateTime 

Pour Décembre 2008:

SELECT * FROM DBMaintSched WHERE ServerID = 'SQLSERVER01' AND Month = 'DEC' AND Year = 2008 ORDER BY DAY ASC 

Vous avez tous les jours pour décembre 2008 sur lequel la maintenance peut être effectuée. Afficher comme vous le souhaitez

1

Chaque solution proposée est bonne pour moi, de toute façon je considérerais celui-ci si vous rencontrez des problèmes de performance et/ou de taille de table. Puisque vous feriez probablement une relation entre le temps et votre entité (c'est-à-dire un serveur), la taille augmentera par entity_number * entity_times. Si vous avez une rangée pour chaque période de temps cela pourrait être une douleur.

Cette proposition est un peu plus laide en termes de structure de table mais plus efficace en termes d'espace disque et de vitesse de balayage de table.

TABLE times 
    entityFK int -- your entity foreign key 
    day INT  -- 0-7 day identifier 
    bit time0 -- ON if the time 00:00 - 00:59 is being covered 
    bit time1 
    bit time2 
    -- more columns 
    bit time23 

Prenons l'exemple où vous souhaitez attribuer 16h00-20h00 disponibilité à un serveur dimanche et lundi, vous aurez seulement deux rangées comme

entityFK | day | time16 | time17 | time18 | time19 | -- other bits are set to 0 
server1 0  1  1  1  1 
server1 1  1  1  1  1 

Vous assumerez que chaque ligne manquante signifie que le serveur est en panne.

Si vous en avez besoin, vous pouvez envisager d'utiliser un format DATE pour la colonne jour afin de définir des dates spécifiques (par exemple, la disponibilité entre le 16/10 et le 20/06/2013 uniquement).

Hope it helps

Questions connexes