Speichern von Zeitplaninformationen

Question

Ich muss eine Tabelle erstellen, die einen Zeitplan für Besprechungen enthält.

Täglich 'Immer X Tage: kann ein Treffen sein wird geplant. wo X zwischen 1 und 6 sein kann. Beenden nach X-Sitzungen. "Sitzungen" sind im Grunde die Anzahl der Wiederholungen.

Wöchentlich An welchen Tagen in der Woche kann es vorkommen. Mo, Di usw. Kann mehr als einen Tag pro Woche auswählen. Das Datum, an dem es endet.

Monats Verwenden Tag des Monats wählen kann (1., 2. usw.) ODER sie aus einer Nachschlag von ‚1., 2., 3., 4. oder Last‘ auswählen und einen Tag ‚Mon auftreten können , Di ', zum Beispiel "Der 2. Freitag" des Monats.

Wie kann ich alle diese Szenarien in einer einzigen Tabelle speichern?

Ich dachte:

CREATE TABLE schedule 
(
    ID INT NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    StartDate DATETIME NOT NULL, 
    EndTime TIME NULL, 
    RepeatTypeID INT NOT NULL, // Daily, Weekly, Monthly, None 
    // For Daily 
    EveryDayCount INT NULL, // to handle 'every 3 days', 
    RepeatCount INT NULL, // How many occurances. Can be shared with different RepeatTypes 
    // weekly 
    IsMonday BIT, 
    IsTuesday BIT, 
    etc // A field per day selection. Is there a better way? 
    // Monthly 
    MonthlyDayNumber INT NULL, 
    MonthlyRepeatIntervalID INT, // Lookup table with '1st, 2nd, 3rd, 4th, Last' 
    MonthlyDayRepeatSelection INT // Lookup on Monday, Tuesday etc 
) 

Aber das scheint ineffizient. Gibt es für diese Anforderungen ein besseres Designmuster?

Answer 1

Auch wenn Sie täglich, wöchentlich, monatlich usw. haben bedeutet immer noch, dass ein Treffen an einem bestimmten Tag stattfinden wird ... richtig?

So

CREATE TABLE schedule 
(
    ID INT NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    StartDate DATETIME NOT NULL, 
    EndDate DATETIME NOT NULL, 
    RepeatTypeID INT NOT NULL, // Daily, Weekly, Monthly, None 
    RepeatCount INT NOT NULL, 
    DayOn INT NOT NULL, // can be a calculated field based on start date using DAY function 
) 

Ich glaube, das Ihr alle Optionen Zeitplan erfassen kann.

Answer 2

Also im Grunde habe ich einmal die gleiche Funktionalität implementiert und ich fand, dass eher als Leichtigkeit der Speicherung, die Leichtigkeit des Abrufens und Bearbeiten/Aktualisieren von größter Bedeutung war.

Sie möchten nicht alle Daten jedes Mal berechnen, die DB nach Besprechungsterminen abfragen oder sagen, dass Sie eine Funktion wie showAllMeetingsForADate(somedate date) haben, dann würden Sie keine Daten zur Besprechung zur Laufzeit berechnen wollen.

Ganz allgemein ist der optimalste Speicher, dass Sie die Berechnungslogik für Besprechungsinformationen in einer Tabelle und alle Besprechungstermine in einer anderen Tabelle wie unten speichern.

Jedoch für die Speicherung von Besprechungsinformationen sollten Sie mit einem normalisierten Formular gehen.

Plan Detailtabellen

CREATE TABLE DailyScheduleDetails 
(
    ScheduleDetailsID INT PRIMARY KEY IDENTITY(1,1), 
    RecurrenceCount INT NOT NULL 
) 

CREATE TABLE WeeklyScheduleDetails 
(
    ScheduleDetailsID INT PRIMARY KEY IDENTITY(1,1), 
    OnMonday bit, 
    OnTuesday bit, 
    OnWednesday bit, 
-- ... 
    OnSunday bit, 
    EndByDate Date NOT NULL 
) 

CREATE TABLE MonthlyScheduleDetails 
(
    ScheduleDetailsID INT PRIMARY KEY IDENTITY(1,1), 
    MonthlyDayNumber INT NULL, 
    MonthlyRepeatIntervalID INT, // Lookup table with '1st, 2nd, 3rd, 4th, Last' 
    -- Here I'd suggest using 0 for Last 
    MonthlyDayRepeatSelection INT // Lookup on Monday, Tuesday etc 
) 

Schedule

CREATE TABLE schedule 
(
    ID INT NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    StartDateTime DATETIME NOT NULL, 
    EndDateTime DATETIME NULL, 
    RepeatTypeID INT NOT NULL, // Daily, Weekly, Monthly, None 
    ScheduleDetailsID INT 
) 

MeetingDates

CREATE TABLE MeetingDates 
(
ID INT NOT NULL PRIMARY KEY IDENTITY(1,1), 
MeetingID int, 
MeetingStartDate datetime, 
MeetingEndDate datetime -- because you can have meeting spanning days like 11:00 PM to 1:00 AM 
--,user or guest information too 
,CONSTRAINT FK_MeetingDates_Schedule FOREIGN KEY (MeetingID) 
    REFERENCES Schedule(ID) 
) 

Answer 3

Verwenden Sie ein n bestehenden Standard. Dieser Standard ist iCalendar RRules und ExDates.

speichern Sie einfach die Rezidiv Regel in der db als varchar

Verwenden Sie eine existing library (C#) anstehende Termine berechnen