Un sistema di prenotazione auto è una domanda molto popolare nelle interviste di sviluppo software. Ho progettato la seguente struttura ER/struttura OOP quando mi è stato chiesto questo:Intervista di progettazione - Sistema di prenotazione auto
classe Car/tavolo ha Auto ID, Tipo (Compact, Standard, ecc), marca, modello cliente ha ID cliente #, ecc La prenotazione è una tabella associativa che memorizza l'ID veicolo, l'ID cliente e la data per cui l'auto è prenotata. Per semplicità, possiamo supporre che l'auto possa essere prenotata solo in blocchi di giorni.
Ecco la parte difficile in cui mi annaspava - Cosa succede quando un cliente 1 riserva una vettura compatta con Id Auto 3 il 27 luglio Cosa succede se Auto 3 è pari a luglio 24. Altre vetture compatte sono disponibili, tuttavia tra 24 e 27 luglio vengono tutti presi. Quindi, quando il cliente 1 arriva il 27 luglio, alla fine non ha la macchina.
Il difetto credo sia nel modo in cui Auto e Cliente sono accoppiati nella tabella Prenotazioni. C'è un modo migliore per modellare questo rapporto e anche i casi d'uso regolari, trovare una macchina a disposizione per una data particolare, riserva per quella data, ecc
Poi arriva la domanda: a che punto vogliamo verificare se la macchina funziona? Una sceneggiatura serale che esegue e sostituisce tutte le auto totali/danneggiate con altre equivalenti funzionanti? –
Hai scelto di utilizzare il modello Entity-Relation. Un 'Car' e un' Customer' sono sicuramente entità. 'Reservation' è sicuramente una relazione tra un' Car' e un 'Customer'. Se una 'Car' è totalizzata/danneggiata è sicuramente una' proprietà' dell'entità 'Car'. Questo design è fedele ai principi del modello Entity-Relation e dovrebbe resistere ai diversi casi d'uso che vengono lanciati su di esso. Compresa la tua ultima domanda. –