Как сохранить доступность практикующего (день недели и время дня) в SQL Server

Question

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

Форма ввода / отображения для этой информации будет в виде таблицы с днями недели в качестве заголовков столбцов, ивремя дня в качестве заголовков строк.Флажки покажут, доступен ли практикующий врач в течение указанного времени.

Мне трудно понять, как сохранить эту информацию в базе данных.Наиболее очевидное решение - создать таблицу с 24 столбцами (21 для 7 дней * 3 раза, 1 в качестве первичного ключа и 1 для внешнего ключа, ссылающегося на специалиста, и 1 для комментария).Это дрянная таблица, но, по крайней мере, ее легко выбирать и обновлять.

Другое решение - создать таблицу с атрибутами:

• Practitioner_id :: int (внешний ключ и первичныйключ)
• day_of_week :: int (первичный ключ) (также может быть Enum, но я не думаю, что SQL Server имеет такой тип)
• morning :: bit
• днем :: бит
• вечером: бит

Это менее уродливая таблица, но обновлять ее будет непросто, поскольку мне нужно было бы иметь отдельный оператор обновления для каждого днянедели.Комментарий также должен храниться вне этой таблицы.

Еще одним решением может быть использование одного столбца для каждого дня недели с типом данных BLOB (или любой другой версией SQL Server).,А затем сохраните информацию о времени в виде массива размера три.Но я уверен, что это нарушает все правила хорошего дизайна базы данных.Это также ограничивает эффективность отдельных запросов.

Любые идеи относительно того, как хранить эти данные?

РЕДАКТИРОВАТЬ:

Чтобы уточнить, нас интересует только то, что ихСреднее недельное расписаниеТакие вещи, как праздники и каникулы, можно игнорировать.

На внешнем интерфейсе информация будет отображаться в виде сетки, со столбцами, представляющими дни недели, и строками, представляющими время дня.

Эта информация может потребоваться для поиска.Например, мы можем захотеть получить отчет обо всех практикующих, которые работают по вечерам в понедельник.

Answer 1

Я бы предложил следующий дизайн, отношение многих ко многим.

table: practitioners
- practitioner_id

table: schedule_blocks
- schedule_block_id

table: practitioners_to_schedules
- practitioner_id
- schedule_block_id

Когда я проектирую, я использую взгляд на срок службы системы и каковы вероятные изменения, которые будутдобавлено.Этот проект требует немного больше усилий заранее, но экономит усилия с течением времени.

Запись записывается только в таблицу Practitioners_to_schedules, когда практикующий доступен.Это может уменьшить размер таблицы и привести к более узкому количеству записей на страницу данных / индекса.

Одним из преимуществ вышеупомянутой конструкции является то, что она не жестко кодирует текущее расписание, «разбивая» на части.схемы.Если бы в будущем система разбивала «куски» на часы, схема таблицы не изменилась бы, только содержимое таблиц.

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

Это позволяет использовать относительно простую схему индексации.Два индекса для Practitioners_to_schedules, и вы можете сообщить о большинстве вариантов эффективно.В зависимости от того, какие операции чтения являются наиболее распространенными, вы можете решить, какой идентификатор использовать для кластеризованного индекса.

Answer 2

Похоже, что ваш второй дизайн стола будет лучше соответствовать вашим потребностям:

practitioner_id :: int (foreign key and primary key)
day_of_week :: int (primary key)
morning :: bit
afternoon :: bit
evening :bit