Ho cercato di dargli una possibilità senza pensarci troppo e questo è quello che mi è venuto in mente:
Room
----
| ID | No. | Type | Price | Beds | Hotel| Size | Minibar | Images | Booked |
| ---|------|---------|---------|----- | --- | ---- | ----- | ----- | ----- |
| 1 | 101 | Deluxe | 5000.00 | 2 | A | 31m^2 | yes |
| 2 | 102 | Economy | 4000.00 | 1 | A | 25m^2 | no
| 1 | 103 | Deluxe | 5000.00 | 1 | A | 31m^2 | yes
| 2 | 104 | Suite | 9000.00 | 2 | A | 50m^2 | yes
Room continued
| ID | TV | Bathroom
| ---| -------- | ------
| 1 | 32inch(hdtv) | Private
| 2 | 30inch(flat) |
| 1 | |
| 2 | 70inch(LED) |
Vedo che ci sono molti servizi che appartengono a una stanza e ho cercato di creare una colonna per ognuno, ma ha iniziato a sembrare pelosa. Inoltre, la colonna Hotel sarà un campo many2one e anche Images .
So che le informazioni sulla prenotazione non dovrebbero appartenere a Room , invece dovrebbe andare a Booking table. Sto pensando dove dovrebbe andare l'ora della prenotazione e il check-out? in Booking tabella?
Oltre a queste informazioni, quali altre informazioni devo mantenere?
Aggiorna
Durante la progettazione dello strato di persistenza ho osservato che il problema è lo stesso della programmazione. Devo mantenere un buon equilibrio tra le tabelle in modo tale da mantenere un basso accoppiamento e un'elevata coesione.
Usa caso
C'è un merchant che può avere molti hotels probabilmente a molti locations . Dato un utente, può verificare la disponibilità di rooms in un determinato hotel e dovrebbe essere in grado di prenotare un room per un determinato periodo di tempo.
