Quanto è importante la normalizzazione dei database in un database molto semplice?

Question

sto facendo una base di dati molto semplice (mysql) con essenzialmente due tipi di dati, sempre con un rapporto di 1 a 1:

Eventi

• Sponsor
• Time (opzionale)
• Posizione (città, stato)
• Venue (opzionale)
• Dettagli URL

Sponsor

• Nome
• URL

Le città verrà duplicata spesso, ma c'è davvero molto valore ad avere un tavolo per una città così semplice schema di database?

La banca dati è popolato da screen-scraping di un sito web. Su questo sito il campo città è popolata tramite una selezione da un menu a discesa, quindi non ci sarà mistypes, ecc e sarebbe facile da abbinare i record con un tavolo città. Solo che non sono sicuro che ci sarebbe molto di un punto, anche se gli utenti del mio database saranno alla ricerca per città di frequente.

Answer 1

normalizzare il database ora.

E 'molto più facile da ottimizzare le query sui dati normalizzati di quanto lo sia per normalizzare un mucchio di dati.

È dire che è semplice ora - queste cose hanno una tendenza a crescere. Progettare bene e si otterrà l'esperienza di una corretta progettazione e un futuro proofing.

Answer 2

Penso che si sta guardando le cose nel modo sbagliato - si dovrebbe sempre normalizzare meno che non abbiate una buona ragione per non farlo.

Confidando l'applicazione per mantenere l'integrità dei dati è un rischio inutile. Tu dici che i dati è reso uniforme perché viene scelto da un menu a discesa. Che cosa succede se qualcuno hack sulla forma e modifica i dati, o se il codice consente inavvertitamente un param querystring con lo stesso nome?

Answer 3

Dove saranno i dati della città si popola da quella tua casella a discesa per l'utente? non si vuole un tavolo per questo?

Sembra che si sta trattando Località come un attributo tra cui città e lo stato. Si supponga di voler ordinare o analizzare gli eventi di stato da solo piuttosto che città e lo stato? Questo potrebbe essere difficile da fare se non si dispone di un attributo per lo stato. Logicamente mi aspetterei stato di appartenere a una tabella della città -. Anche se questo può dipendere da esattamente come si desidera identificare le città

Answer 4

Risposta diretta: Solo perché un problema è relativamente semplice è alcun motivo per non fare le cose per mantenere le cose semplici. E 'molto più facile a camminare coi piedi che sulle mie mani. Non ricordo mai dire: "Oh, ho solo andare mezzo miglio, che è a breve distanza in modo potrei anche camminare sulle mie mani."

Più rispondere: Se non tenere tutte le informazioni su una città diversa da suo nome, e non si dispone di un elenco di pre-serie di città (ad esempio, per costruire un menu a discesa), allora lo schema è già normalizzato. Quale sarebbe in una tabella City diverso dal nome della città? (Presumo Stato non può essere dipendente da città perché si potrebbe avere due città con lo stesso nome in diversi stati, ad esempio, Dayton OH e Dayton TN.) La regola rilevante della normalizzazione è "dipendenze non-chiave", che è, non si può disporre di dati che dipende dai dati che non è una chiave. Se tu avessi, diciamo, latitudine e longitudine di ogni città, quindi questi dati si sarebbe ripetuto in ogni record che ha fatto riferimento nella stessa città. In quel caso si sarebbe certamente voglia di uscire una tabella città separata per contenere la latitudine e la longitudine. Si potrebbe, naturalmente, creare un "codice di città", che è un numero intero o l'abbreviazione dei link ad un tavolo città. Ma se non ci sono altri dati su una città, non vedo come questo guadagni nulla.

Tecnicamente, presumo che dipende dalla Città Venue. Se il luogo è "Rockefeller Center", che implica che la città deve essere di New York. Ma se sede è facoltativa, questo crea problemi. Una possibilità è quella di avere un tavolo Venue che le liste sede nome, città e stato, e per i casi in cui non si specifica il luogo, hanno un "non specificato" per ogni città. Questo sarebbe più corretto da manuale, ma in pratica se nella maggior parte dei casi non è necessario specificare un venu, sarebbe guadagnare poco. Se la maggior parte del tempo si specifica un venu, probabilmente sarebbe una buona idea.

Oh, e, c'è davvero un 1: 1 relazione tra evento e sponsor? Posso credere che un evento non può avere più di uno sponsor. (Nella vita reale, ci sono un sacco di eventi con più sponsor, ma forse per i vostri scopi che si preoccupano solo di un "sponsor primario" o qualcosa del genere). Ma fa uno sponsor non detengono più di un evento? Che sembra improbabile.

Answer 5

Perché non , andare avanti e normalizzare? Si scrive come se vi sono costi significativi di normalizzazione che superano i benefici. E 'più facile per configurarlo in una forma normale prima di popolare è che cercare di normalizzare in un secondo momento.

Inoltre, mi chiedo il vostro rapporto 1-a-1. Ingenuamente, mi immagino che un evento potrebbe avere più sponsor, o che uno sponsor potrebbe essere coinvolto in più di un evento. Ma io non conosco la logica di business ...

ETA: Non so il motivo per cui non ho notato prima, ma se siete veramente contrari a normalizzare il database e si so che si avrà sempre un rapporto 1 a 1 tra gli eventi e sponsor, allora perché si hanno gli sponsor in una tabella separata?

Sembra che si può essere un po 'confuso su ciò che la normalizzazione è e perché si dovrebbe farlo.

Answer 6

Le cerniere risposta, IMO, se si vuole evitare errori durante immissione dati. Se lo fate, avrete bisogno di una tabella SEDI:

VENUES
City
State
VenueName

così come un tavolo da città e stati. (Nota:.. Ho visto situazioni in cui la stessa città si verifica più volte nello stesso stato, città solitamente più piccole, in modo da Città / Stato non comprendono una diade unica Normalmente c'è un codice postale per disambiguare)

Per evitare situazioni in cui l'operatore di data-entry entra sede di New York New York che è in realtà in SF CA, avresti bisogno di convalidare l'entrata location per vedere se tale luogo esiste in città / stato fornito sul record .

Allora avresti bisogno di fare CITTA '/ STATO obbligatoria, e deve scrivere il codice per eseguire il rollback la transazione e gestire l'errore.

Se non siete preoccupati per far rispettare questo tipo di accuratezza, allora non si ha realmente bisogno di avere tavoli CITY e stati sia.

Answer 7

Se siete interessati a conoscere la normalizzazione, si dovrebbe imparare cosa succede quando non si normalizzare. Per ogni forma normale (1NF oltre) c'è un aggiornamento anomalia che si verifica come conseguenza di ridondanza dannose.

Spesso è possibile programma intorno alle anomalie di aggiornamento, e, talvolta, che di più pratico di sempre normalizzando al grado finale.

A volte, è possibile per un database di entrare in uno stato incoerente a causa di mancanza di normalizzare, e l'incapacità di programmare l'applicazione per compensare.

Nel tuo esempio, il meglio che può venire in mente è una sorta di zoppo hypotheical. Che cosa succede se il nome di una città ha ottenuto mispelled in una riga, ma scritto correttamente in tutte le altre. Che cosa succede se si riassunto da città e sponsor? L'output rifletterebbe l'errore, e il gruppo uno diovide in due gruppi. Forse sarebbe meglio se la città fosse scritto solo una volta nel database, nel bene e nel male. Almeno il raggruppamento per la sintesi sarebbe corretto, anche se il nome fosse mispelled.

E 'questo vale per nromalizing? Ehi, è il vostro progetto, non il mio. Si decide