Как спроектировать модель для хранения суточных таймингов?

#mongodb #schema

#mongodb #схема

Вопрос:

Я разрабатываю схему для назначений врача. Врачу будет предоставлена возможность обновлять свои расписания для отдельных дней месяца. Также нет ограничений по месяцам. Например, врачи смогут обновлять расписания для любых дней будущего или текущего месяца. (Будут отключены только предыдущие даты). Внешняя часть была выполнена, но чего я не понимаю, так это как создать для нее модель mongo. Конечно, у меня не может быть дат для всех месяцев, сохраненных в модели. Каков метод решения этой проблемы? TIA

Ответ №1:

Если бы у меня был такой проект, я бы начал с 5 коллекций:

  • один для пользователей (чтобы вы знали, кто что сделал)
  • один для пациентов (запись всех сведений о пациенте, включая номер мобильного телефона)
  • один для врачей (чтобы вы могли показывать список при регистрации времени)
  • одна регистрация за время (со всеми деталями регистрации)
  • один для протоколирования всего, что делает пользователь

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

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

Я бы подумал о чем-то между этими строками:

 // Users
{
  username, hashedPassword, // credentials
  permissions: [], // for when you start using permissions
  active, // never delete data, just set the flag to "false", if, by GDPR rules you need to delete, you can change the name to "DELETED BY GDPR" and still maintain all references
}

// Patients
{
  name,
  address: { street, street2, city, zipcode, country }, // for invoicing proposes
  mobile, // so you send them an SMS 24h before saying their appointment is "tomorrow"
}

// Doctors
{
  name,
  weekAvailability: [], // days of the week that a doctor is available as they normally work in more than one clinique
  active, // never delete data, just set the flag to "false", if, by GDPR rules you need to delete, you can change the name to "DELETED BY GDPR" and still maintain all references
}

// Logs
{
  action, // for example, "save", "add", "change"...
  entity, // the collection name that the change happened
  originalEntry, // the full document before changes
  newEntry, // the full document after changes
  timestamp, // the exact time of the change
  user, // ref to users
}

// TimeRegistrations
{
  user, // ref to users
  patient, // ref to patients
  doctor, // ref to doctors
  title, description, appointmentStart, durationInMinutes,
}
  

что касается инфраструктуры… создайте API (REST или GRAPHQL, тот, с которым вам удобнее всего), чтобы вы могли с самого начала отделить бизнес-логику от интерфейса

ваш интерфейс (возможно, React, Angular, VueJS) должен вызывать прокси (сервер NodeJS, работающий в стороне от интерфейса) для аутентификации и вызова API, поэтому все, что вам нужно сделать во внешнем интерфейсе, должно быть чем-то вроде

 fetch('/api/doctors')
  .then(res => res.toJson())
  .then(json => {
    this.doctorsList = json
  })
  

то же самое, что и для аутентификации os a user , где вы можете легко использовать библиотеку, которая предоставит вам JWT и легко поддерживать пользователя, вошедшего в систему, с правильным набором разрешений

Ответ №2:

Первый подход, но не очень хороший в вашем случае, т. Е. Одна коллекция,

 //doctors
{
   _id: "",
   appointments: [] // all appointments there
}
  

Второе будет лучше, но обратите внимание, что в коллекции NoSQL полностью зависит от того, как вы хотите получить данные. Две коллекции:

 //doctors
{
   _id: "SOMETHING",
   name: "SOMETHING"
}


//appointments
{
   _id: "SOMETHING",
   doctorId: "", // ref of doctor collection
   appointmentAt: "",
   appointmentAtMilli: "",
}