Tabella di giunzione relativa a un'altra tabella di giunzione

Question

Tabella di giunzione relativa a un'altra tabella di giunzione

#1 da (4 voti)
#2 da (4 voti)

6

Sto definendo una struttura DB e ho la netta sensazione che non lo stia facendo bene. Ho degli hotel che possono essere configurati per offrire alcuni servizi opzionali (pick-up in aeroporto, massaggi), che a loro volta possono essere prenotati con una camera. Quindi, ogni hotel sceglie i servizi che offre e il prezzo. Attualmente ho le seguenti tabelle (semplificate):

Guests (id, (PK), name)
Hotels (id (PK), name)
HotelServices (name (PK))
Hotels_HotelServices (id (PK), hotel_id (FK), service (FK), price_value, price_currency)
Rooms (id (PK), hotel_id (FK), number, capacity, price_value, price_currency)
Bookings (id (PK), guest_id (FK), room_id (FK), date_from, date_to)
Bookings_Hotels_HotelServices (id (PK), hotels_hotelServices_id (FK))

È l'ultimo tavolo che mi disturba di più. Non mi piace avere una tabella di giunzione che punta a un'altra tabella di giunzione, ma non riesco a pensare a un altro modo di rappresentare quali servizi sono stati prenotati con la stanza.

Esiste un approccio migliore e comune alla modellazione di tale situazione?

database database-design relational-database modelling

posta mark951131b 14.01.2016 - 13:22

fonte

2 risposte

Leggi altre domande sui tag database database-design relational-database modelling

Scrivere il tuo framework o usarne uno esistente? [duplicare] Architettura del server per brevi burst di ~ 150 subquery paralleli CPU-heavy

score 4 · Answer 1

Perché hai bisogno di una tripla referenza? Il Savoy è un HOTEL . "Massaggio turco" è un SERVICE . Se la Savoia lo offre, quella è una voce ii la tua tabella H_S .

Se qualcuno sta alla Savoia, quella è una voce nella tabella BOOKING che punta all'hotel; se ordinano anche un massaggio, questa è una voce nella tabella B_S che punta alla prenotazione e al servizio. Non è necessario puntare a H_S anziché direttamente a SERVICE .

Modifica. Se le tue definizioni di "servizio" variano nel prezzo da hoptel a hotel, e tutto a cui sei interessato è il prezzo, quindi sicuro, dovresti conservare il prezzo giusto nella tabella H_S e nemmeno una tabella SERVICE . Ma se i servizi hanno attributi propri che è necessario recuperare (ad es. Per descriverli in bolletta), allora dovrebbero sempre andare in una tabella separata a cui ci si unisce come necessario. Dati quasi-statici come le definizioni di modelli o servizi con un paio di migliaia di righe o migliaia di righe non sono in realtà "big data" - i motori di database fondamentalmente ridono di ciò. Sono solo quelli con un potenziale di crescita illimitato (ad es. Commenti sui social media) in cui l'efficienza di accesso di solito diventa un problema.

score 4 · Answer 2

Non sono sicuro che i servizi dell'hotel siano "prenotati con la camera". Che dire delle sale conferenze o dei pass per la piscina tutto il giorno?

Gli hotel hanno clienti che non sono ospiti, quindi un'entità "CLIENTE" è un vestito migliore. Un cliente che soggiorna in una stanza è un ospite.

Inoltre, entità / tabelle dovrebbero avere nomi singolari.

Modifica

Nonc'èassolutamentealcunproblemainquellechechiamate"tabelle di giunzione" che hanno relazioni con altre "tabelle di giunzione". Spesso le tabelle di giunzione hanno nomi di dominio aziendali che danno loro un nome di entità legittimo. Ad esempio una tabella di giunzione tra lavoratori e navi dovrebbe essere chiamata CREW invece di WORKER_SHIP. In questo modo ciò che ti infastidisce sulla relazione tra i tavoli di congiunzione potrebbe infastidirti di meno.