Come strutturare un sistema di prenotazioni in un database basato su documenti?

1

Non so davvero se questo è il forum giusto per questo, ma ho bisogno di aiuto per progettare il mio database. Inoltre mi scuso per il titolo orribile: non so come riassumere il problema qui sotto in un singolo titolo.

Sto costruendo un sistema di prenotazione in cui una prenotazione può avere più servizi. Qualcosa come il seguente (documento singolo):

{
    name: 'Gasim',
    start_date: '2015-07-24 1:30pm',
    services: [
      {member_id: 'member1', start_date: '2015-07-14 1:30pm', duration: '40 mins'},
      {member_id: 'member2', start_date: '2015-07-14 2:30pm', duration: '60 mins'}
    ]
}

Avevo intenzione di seguire questo progetto, ma dopo aver avuto molti dibattiti con un certo numero di persone, ho perso la fiducia nell'andare con questo design. Mi è stato detto più volte che dovevo creare una prenotazione separata per ciascun servizio invece di aggregare i servizi con un'unica prenotazione. Anche se mi piace l'idea che mi sia stata proposta, ho un grosso problema e vorrei che tu facessi luce su questo problema per me.

Tutti questi servizi vengono assegnati in un singolo periodo di tempo. Quindi, diciamo l'esempio sopra, il tempo totale per una prenotazione è di 100 minuti con 20 minuti di attesa = 2 ore.

Se li separo, significa che in realtà ho due riserve. In uno scenario di programmazione questa può essere una buona idea, ma guardiamo da uno scenario reale. Dopo aver fatto una prenotazione, vengo nella struttura e dico che ho una prenotazione sotto il mio nome. Perché la reception dovrebbe vedere due prenotazioni separate sotto il mio nome?

Ho intenzione di fornire alcune informazioni di base su come questa cosa diventa un problema. Il mio sistema ha la capacità di interrogare tutte le prenotazioni, passare attraverso i loro servizi e generare un elenco di orari disponibili in base ai servizi che un utente desidera. Mi aspetto davvero che questo algoritmo sia lento poiché sto attraversando molti array e loop annidati. Tuttavia, questa operazione specifica verrà recuperata ad una velocità molto piccola anche a scale grandi (non credo che supererà mai 1000 richieste / secondo, punto).

Domanda

Questo design è corretto? Non per quanto riguarda le prestazioni, ma solo per quanto riguarda la logica. Non voglio che il mio progetto sia logicamente difettoso solo perché rende alcune operazioni veloci. Se questo non è un progetto corretto, puoi spiegare perché?

    
posta Gasim 21.07.2015 - 11:13
fonte

1 risposta

3

sbarazzarsi del DB basato su documenti, è un sistema orribile per il tipo di query che farai. Torna al noioso vecchio RDBMS e sarai molto più felice.

Se lo fai, non solo puoi effettuare prenotazioni singolarmente (il che aiuta anche quando qualcuno aggiunge un servizio alla loro prenotazione) ma puoi interrogare tutti i servizi assegnati con un unico ID di prenotazione. Semplice ed efficiente.

Quindi ho una biblioteca con i libri. Posso controllare un libro e scrive una voce nel DB contro quel libro con il mio userid per dire chi lo ha prenotato e può scrivere l'ora in cui dovrei restituirlo. Il giorno dopo torno indietro e controllo un altro libro, questo scrive una voce come prima. Quando guardi il mio ID utente, la reception può vedere entrambi i libri che ho verificato perché la query per restituire i miei dettagli è un semplice select * from reservations where user id = x .

Puoi estenderlo facilmente per includere molte prenotazioni includendo una tabella di prenotazioni che effettuo (collegando il mio ID utente con le prenotazioni) e quindi collegando i servizi all'interno di quelle prenotazioni con l'ID di prenotazione. Ad esempio, ho un account separato per libri e musica in biblioteca, ogni libro viene associato al mio account "book lending" e non a me - funziona ancora molto facilmente con un RDBMS tradizionale.

    
risposta data 21.07.2015 - 11:50
fonte

Leggi altre domande sui tag