Прошу помощь в организации системы записи по дням?

Question

[doctorcat]

Приветствую, коллеги.

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

{
	"fio": "Юдина Любовь Викторовна"
	years: {
		"2018": {
			days: {
				//тут 365 элементов. столько же сколько и дней
				"day1": {
					time: "12.00"
					pacien: "zalupin vasya"
					problems: "hz"
				}
			}
		}
	}
}

Answer 1

[eternalfire]

если делать так, то один объект каким то монструозным получается, нужно несколько документов

1 - врачи

{
  id: 1,
  fio: "Юдина Любовь Викторовна",
  schedule: 1
}
{
  id: 2,
  fio: "Иванов Иван Иванович",
  shedule: 1
}

естественно потом эту сущность можно дополнительными данными забить, типа специализации, часы приёма, сколько дней в неделю и какие на работе и тд

2 График
Можно завести отдельную коллекцию для графиков работ

{
  id: 1,
  begin: Date,
  end: Date,
  days: ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]
}

где как раз есть время начала и окончания рабочего дня и сами дни работы

Так же можно добавить отпуски выходные и так далее, что угодно

Можно также её объединить с сущностью врач, но это кому как нравится

3 - Запись о посещении

{
  id: 1,
  pacient: "zalupin vasya",
  problems: "hz",
  time: "12:00",
  specialist: 2,
  date_create: '2016-05-18T16:00:00Z'
}
{
  id: 2,
  pacient: "Vasya",
  problems: "hz",
  time: "12:00",
  specialist: 2,
  date_create: '2016-05-18T16:00:00Z'
}

Ключ специалист содержит ссылку на врача из документа 1, а по ключу date_create можно формировать выборку

А так формировать данные как вы хотите, это вообще не правильно)

Comments

[doctorcat]

я не сталкивался с архитектурными задачами, и не видел реализации подобной системы. Благодарю за ответ. Но вот с днями вопрос остаётся открытым. То есть планируется запись вперёд на 2 недели и хранение данных обо всех приемах у каждого врача и пациента в течении года. Вот тут я не совсем понимаю... Как мне во первых сделать структуру что бы она выдавала в какое время врач занят а в какое сможет принять. По дням и по часам. Во вторых как вообще работать со временем и его хранением в данном контексте. Например определить какой именно день недели (к примеру пятница). Вообще плаваю в этой теме, если можно ссыль на какую-то инфу или реализацию. Чувствую что вообще не туда мыслю

[Ди Ма]

doctorcat, На сайте клиент выбирает врача. Получаем все записи о посещениях, в которых specialist == выбранный клиентом врач.

А далее можно по разному. Например, нарисовать календарь. Если у врача в этот день мало записей- окрашиваем день в зеленый. Если много записей - в красный. По градиенту. А если кликнуть на какой-то день- то открывается таблица с часами (типа как на картинке), где свободные часы доступны для записи (можно кликнуть и записаться).

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



Ну и datepicker

[eternalfire]

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

2. Насчёт часов приёма, У сущности врач, нужно добавить ключ часы приёма и записать интервал в который он доступен, следовательно всё остальное время - он не доступен. Можно сделать ещё глубже, сам видел, что они работают обычно по чётным дням в один период времени, а по нечётным - в другой. Ведь в момент создания заявки на приём, вы знаете время на которое она оформляется, текущий день, следовательно вы знаете доступен ли врач в это время.

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

[eternalfire]

и тем более подобный вопрос уже встречался
Где почитать про проектирование баз данных(nosql) с практическими примерами?

Answer 2

[Артем Спиридонов]

Сетка нужна. Какое-то решение о рабочем времени, делящимся на "окна".

Перед добавлением записи проверять наличие "окошек". При добавлении - проверять, что оно происходит именно в свободное "окно".

Предусматривать в БД по строке на каждое окно не обязательно. Разделите задачу на интерфейс, визуализацию (в соответствии с принципом окон, учитывая время приема и т.д., учитывая уже занятые "окна") и саму запись. Тогда все будет просто, тривиально.