2013-02-10 14 views
7

Mi è stato chiesto di descrivere cosa c'è di sbagliato in questa struttura dati e come migliorarlo.Cosa c'è di sbagliato in questa struttura dati?

Ecco la struttura dei dati:

Image

Ecco quello che ho finora:

prezzo
  • la macchina è impostata solo se l'auto è in showroom, sarebbe ha più senso inserire il prezzo dell'auto nel tavolo dell'auto

  • Non ha senso memorizzare dati NULL nella tabella auto, sarebbe una scommessa ter di avere un layout simile a questo:

    Car table

  • ci deve essere un quantitativo dirigendo per mostrare come molti di quella particolare macchina sono nello showroom come alcuni showroom hanno multiplo delle stesse vetture

Il nuovo tavolo che ho tracciato ha ancora dati ripetuti, che ricordo vagamente è un no no quando compongo una struttura dati, e quindi penso di aver bisogno di fare un terzo tavolo? Non sono davvero sicuro ...

Ho solo bisogno di un po 'di aiuto su cosa c'è di sbagliato nell'attuale struttura dati e se c'è un modo per migliorarlo, qualsiasi aiuto è apprezzato.

+0

FWIW, si intende 'schema del database' non 'struttura dati' – Patashu

+0

@Patashu: lo schema è solo nome-spaziatura - una raccolta di oggetti. La struttura è di che cosa si tratta. –

+0

li abbiamo appresi come strutture di dati, ma sì è uno schema di database e anche – user2058186

risposta

8

Un problema è che la tabella Car memorizza due cose distinte: memorizza e memorizza i modelli.

così si dovrebbe dividere che fino, qualcosa come:

Rende: colonne makename, makecode

Modelli: colonne makecode (chiave esterna per marche), ModelName, modelcode

E ora tavolo showroom riguarderà solo i modelli, quindi non può fare riferimento a una marca per errore.

Poiché un modello può avere molte righe della tabella showroom ad esso correlate, non è possibile unire le due tabelle in modo significativo, quindi tenerle separate e andare da lì.

+0

grazie mille per la risposta, ho intenzione di andare con i 3 tavoli che hai suggerito :) – user2058186

2

Sei corretto che i dati ripetuti siano verboten.

Vorrei cambiare "showroom" per essere "modello" perché ci possono essere varie sottocategorie di modelli. IE Golf TDI vs GTI e così via. ... e il prezzo base (MSRP) sarebbe applicabile al modello. Mostra lo stato della stanza non ha senso per i prezzi - ci sono molti che sono pubblicizzati ma non nello showroom o sul lotto.

Non penso ci sia alcun problema con l'avere una colonna NULLable, se questo è ciò che i dati supportano. O va bene, e puoi fare un benchmark una volta che hai una buona quantità di dati per vedere cosa ti serve meglio. Ma ottimizza dopo, non prima.

+0

grazie mille per la risposta :) – user2058186

4

Sembra che la struttura dell'auto memorizza sia le marche di auto che i modelli di auto. Questo dovrebbe almeno far scattare qualche allarme. L'auto fa come Ford, VW e Peugeot hanno il loro MakeCode. I modelli di auto come Fiesta e Golf hanno il loro ModelCode.

Nella struttura originale, modelli di auto si riferiscono a loro fare attraverso il ParentCarId e duplicare loro MakeCode. Le marche di autoveicoli non sono modelli specifici e vengono assegnati null per il loro ModelCode e ParentCarId.

Il ParentCarId non ha senso, cosa significa per un'automobile essere figlia di un altro? Invece, una macchina appartiene a una marca che è un'altra entità rappresentata da un'altra tabella. Inoltre, le auto non dovrebbero avere uno MakeCode, poiché questo è un attributo della marca a cui appartengono. Chiaramente, le marche e i modelli sono molto distinti e dovrebbero essere rappresentati in diverse tabelle.

Sarebbe sensato dividere il tavolo in due: uno per marche e uno per modelli. Rende sarebbe uno ID, uno Name e uno MakeCode. I modelli avrebbero un , un Name, uno ModelCode e uno MakeId (una chiave esterna per il ID di un Make).

+0

grazie mille per la risposta, ho intenzione di provare che :) – user2058186

Problemi correlati