Как представить запланированные события в СУБД?

Question

Я должен хранить запланированные события (например, например, раз в разное время), которые могут быть организованы еженедельно, ежедневно или ежемесячно. События могут происходить, скажем, каждый понедельник и среду, или каждый второй четверг месяца. Есть ли способ сохранить эту информацию в СУБД, которая придерживается 3NF?

EDIT: Это не домашнее задание; Я строю что-то с другом для нашего собственного назидания, и мы хотим его в 3NF.

Чтобы быть конкретным, я пытаюсь сохранить графики массового и исповеди времен в приходах RC. Их можно планировать множеством способов, например, каждое воскресенье в разное время или каждый раз в другое время. Иногда это только третья пятница месяца, а другие предлагаются только через определенное время раз в год. Мне нужно не только хранить эту информацию, но и запрашивать ее, чтобы я мог быстро получить исчерпывающий список доступных времен в следующий день или неделю или что-то еще.

Я полагаю, что строго говоря, 3NF не является обязательным требованием, но было бы проще для нас, если бы это было так, и было бы лучше сделать это правильно с места в карьер, чем позже изменить нашу схему.

Answer 1

Да Я решил эту проблему с моим сотрудником следующим образом:

CREATE TABLE [dbo].[Schedule](
    [ID] [int] IDENTITY(1,1) NOT NULL, 
    [StartDate] [datetime] NOT NULL, 
    [EndDate] [datetime] NULL 
) 

CREATE TABLE [dbo].[ScheduleInterval](
    [ID] [int] IDENTITY(1,1) NOT NULL, 
    [ScheduleID] [int] NOT NULL, 
    [ScheduleIntervalUnitID] [int] NOT NULL, 
    [Interval] [smallint] NOT NULL 
) 

CREATE TABLE [dbo].[ScheduleIntervalUnit](
    [ID] [int] NOT NULL, 
    [Name] [varchar](50) NULL 
) 

INSERT INTO ScheduleIntervalUnit (ID, Name) 
SELECT '1' AS [ID], 'Day' AS [Name] UNION ALL 
SELECT '2' AS [ID], 'Week' AS [Name] UNION ALL 
SELECT '3' AS [ID], 'Month' AS [Name] 

график охватывает промежуток времени и интервалы происходят в течение этого промежутка времени. Единица интервала расписания определяет длину интервала (дней, как «каждый другой» (2) или «каждую треть» (3) и т. Д.), Неделю (день недели, например, понедельник, вторник и т. Д.) И месяц (календарного года). Используя это, вы можете вести запросы и логику к своей базе данных для получения расписаний.

Если ваши графики требуют лучшего разрешения - вплоть до часов, минут, секунд - посмотрите на реализацию Unix cron. Первоначально я начал с этого маршрута, но нашел выше, чтобы быть более упрощенным и поддерживаемым подходом.

Единый период времени/времени - например, определенный школьный семестр, начинающийся 9 сентября и заканчивающийся 4 ноября, - может содержать несколько графиков (поэтому каждый понедельник для класса Art и «каждый день» для Phys Ed - вам нужно будет больше работать для рассмотрения праздников и выходных дней!).

Answer 2

Чтобы записать правила для «периодического повторения», вы можете принять во внимание формат crontab, за исключением того, что вам не нужны ограничения на минуты и часы, но день недели, день месяца и как. Поскольку в расписании может быть более одного (например,) дня недели, для целей NF вам понадобятся типичные промежуточные таблицы, используемые для представления многих-многих отношений, т. Е. Один с двумя внешними ключами в строке (один к главной таблице событий , один за столом в будние дни) - и аналогично, конечно, за дни месяца и т. п.

Предположительно, каждое запланированное событие также будет иметь продолжительность, категорию, возможно, местоположение, имя или описание описания.

«Как нормаль» является формой (как только вы позаботились о «наборах» с упомянутыми выше многими отношениями) в основном зависит от того, зависят ли эти различные атрибуты друг от друга - например, если каждый событие в определенной категории имеет такую ​​же продолжительность, вы захотите иметь отдельную вспомогательную таблицу с идентификатором, категорией и продолжительностью и использовать внешние ключи в этой таблице, а не повторять парную информацию. Но из того, что вы говорите, я не вижу никакого внутреннего нарушения правил нормальной формы, за исключением таких возможностей зависимостей (которые не присущи тому, что мало вы указали в планировании событий).