Come progettare l'applicazione basata su slot di tempo

• Questi dati possono essere espressi bene in un database relazionale, quindi un database basato su documenti non offre realmente un vantaggio
• Utilizzare le funzionalità di interrogazione del database per restringere la prenotazione al medico e alle date a cui sei interessato e fare l'elaborazione effettiva nell'applicazione dovrebbe funzionare bene. Ci sono forse poche centinaia di prenotazioni al mese e un dottore, il recupero di tutte quelle file è ancora a buon mercato.
• Se necessario, puoi sempre aggiungere un livello di memorizzazione nella cache o denormalizzare le informazioni sulle date prenotate. Ma non mi aspetto che sia necessario.
• La quantità totale di dati sarà piuttosto piccola, quindi probabilmente non avrai bisogno di sharding
• Molti database NoSQL favoriscono lo sharding sulle transazioni, il che probabilmente non rappresenta un buon compromesso per te dato che non avrai bisogno di sharding.

A meno che qualcuno non abbia un modo davvero unico di affrontare questo problema, penserei che comprerebbero qualcosa già costruito perché ci sono problemi di sicurezza e metodi consolidati per farlo.

First of all should I use NoSQL or SQL for this kind of architecture?

Da un punto di vista dell'architettura, entrambi funzioneranno, quindi considera la sicurezza come una considerazione prioritaria per la scelta dell'uno sull'altro. La tecnologia non è il problema, ma è meglio avere accesso a qualcuno che sa davvero come proteggere i dati se stai costruendo app per la professione medica. Anche se vivi in un paese senza restrizioni legali, nessuno vuole trasmettere gli appuntamenti del medico, ricevere una doppia prenotazione o cancellati per errore.

How should I store the time slots of doctors and already booked time slots of patients?

La professione medica e le persone in esso hanno fatto questo genere di cose per molto tempo e probabilmente in un modo particolare. Assicurati di avere un sacco di input da parte dell'utente o ti troverai nei guai. Costruisci prima le strutture dati nella tua applicazione e poi progetta come verranno salvate.

Questo tipo di sistemi di pianificazione finiscono per creare spazi di tempo futuri disponibili. Lo gestirai in modo programmatico nella tua app in base alle esigenze del cliente.

How should I fetch the next available time slots based on the information stored?

Per evitare un sacco di dati vuoti, metti gli appuntamenti in una tabella separata con un link alla fascia oraria aperta. Ciò impedisce un sacco di campi vuoti: client, scopo, note, ecc. Tutto ciò è basato sull'input del cliente che dovresti ottenere.

Non è così difficile vedere se la chiave primaria di un record non esiste in un'altra tabella (preferisco questo a un outer join che cerca una chiave straniera nullo perché mostra l'intento - Vedi SQL sotto.) per determinare quali fasce orarie hanno un appuntamento corrispondente o sono gratuiti. Mi stai chiedendo, "Dammi le fasce orarie aperte per questo (i) medico (i) che non hanno un record di appuntamento corrispondente".

Select * 
From OpenTimeSlot as O
Where Does Not Exist (
Select * 
from ClientAppointment as A 
Where O.PK_ID = A.FK_OpenTimeSlotID)