Я думаю, что эти типы вопросов интересны, потому что, когда вы разрабатываете базу данных, важно знать требования приложения, которые будут взаимодействовать с вашей базой данных.
Это, как говорится, до тех пор, пока приложение может ссылаться на несколько таблиц, я думаю, что ответ Крис Стил является отличным началом, что я буду опираться на ...
Я хотел бы 2 таблицы. Первая таблица делит день на части (фрагменты) в зависимости от бизнес-потребностей организации. Каждый срез будет основным ключом этой таблицы. Я лично выберу 15-минутные кусочки, которые приравниваются к 96 дням. Каждая дневная часть в этой таблице будет иметь «начало блока» и время «блокировки», на которое ссылается приложение планирования, когда пользователь выбрал фактическое время начала и фактическое время окончания собрания. Приложение будет необходимо применить логику такой, как два «ИЛИ» оператор между 3 «и» заявлениями для того, чтобы увидеть, если конкретный blockID будет вставлен в назначениях таблицы:
- фактического пуск> = начало блока и фактическое начать < конца блока
- фактический конец> начало блока и фактический конец < конца блока
- фактическое начало старта < блок и фактический конец> конца блока
Это немного отличается от ответа Криса Стила в го при этом использует две таблицы. Фактические метки времени все еще могут быть вставлены в таблицу ваших приложений, но логика применяется только к ним при сравнении с таблицей TimeBlocks. В моей сервировки, я предпочитаю ломая даты в составные части для анализа кросс-платформенной (наша организация использует несколько СУБД, а также SAS для аналитики):
CREATE TABLE TimeBlocks (
blockID Number(X) NOT NULL,
blockStart DateTime NOT NULL,
blockEnd DateTime NOT NULL,
primary key (blockID)
);
CREATE TABLE Appointments (
mgrID INT NOT NULL,
yr INT NOT NULL,
mnth INT NOT NULL,
day INT NOT NULL,
blockID INT NOT NULL,
ApptStart DateTime NOT NULL,
ApptEnd DateTime NOT NULL
empID INT NOT NULL,
primary key (mgrID, yr, mnth, day, blockID),
CONSTRAINT timecheck
check (ApptStart < ApptEnd)
);
Для обеспечения соблюдения этого ограничения вам нужен триггер или определенную пользователем функцию (по крайней мере, в большинстве баз данных). –
Если это вопрос SQL-запроса, вы можете просто ответить, что во время разработки это невозможно. –
Вы можете сделать это в SQL Server, если вы также моделируете периоды свободного времени, имеете перекрестные ссылки внешних ключей, которые связывают каждый период времени с его предшественником и преемником, и пишут некоторые поистине ужасные утверждения «MERGE» для введения вставки/удаления (где, чаще всего, вам нужно разделить бесплатный период, обновив его, вставив новую строку и вставив новую встречу, все в одном заявлении, чтобы внешние ключи остались довольными). Это выполнимо, но часто затраты выше стоимости. –