Sia che tu stia lavorando con un database che contiene centinaia di record o milioni di record, la corretta progettazione del database è sempre importante. Non solo renderà il recupero delle informazioni molto più semplice, ma semplificherà anche l'espansione del database in futuro. Sfortunatamente, è facile cadere in alcune trappole che possono rendere le cose difficili in futuro.
Ci sono interi libri scritti sul tema della normalizzazione di un database, ma se si evitano semplicemente i comuni errori mostrati qui, si sarà sulla buona strada per un buon design del database.
Errore di database n. 1: ripetizione di campi in una tabella
Una regola empirica di base per una buona progettazione del database è riconoscere i dati ripetuti e inserire le colonne ripetute nella propria tabella. La ripetizione di campi in una tabella è comune per coloro che provengono dal mondo dei fogli di calcolo, ma mentre i fogli di calcolo tendono ad essere piatti in base alla progettazione, i database dovrebbero essere relazionali. È come passare dal 2D al 3D.
Fortunatamente, i campi ripetitivi sono solitamente facili da individuare. Dai un'occhiata a questa tabella:
| ID ordine | product1 | product2 | Product3 |
| 1 | Orsacchiotti | Caramelle gommose | |
| 2 | Caramelle gommose |
Cosa succede quando un ordine contiene quattro prodotti? Dovremmo aggiungere un altro campo alla tabella per supportare più di tre prodotti. E se abbiamo creato un'applicazione client attorno al tavolo per aiutarci a inserire i dati, potrebbe essere necessario modificarlo con il nuovo campo del prodotto. E come troviamo tutti gli ordini con Jellybeans nell'ordine? Saremmo costretti a interrogare ogni campo prodotto nella tabella con un'istruzione SQL che potrebbe essere simile a: SELECT * FROM Prodotti WHERE Prodotto1 = 'Jelly Beans' O Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.
Invece di avere una singola tabella che raccolga tutte le informazioni insieme, dovremmo avere tre tabelle ognuna delle quali contiene un'informazione distinta. In questo esempio, vorremmo una tabella Ordini con informazioni sull'ordine stesso, una tabella Prodotti con tutti i nostri prodotti e un tablet ProductOrders che collega i prodotti all'ordine.
| ID ordine | Identificativo del cliente | Data dell'ordine | Totale |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Codice prodotto | Prodotto | Contare |
| 1 | Orsacchiotti | 1 |
| 2 | Caramelle gommose | 100 |
| ProductOrderID | Codice prodotto | ID ordine |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Si noti come ogni tabella ha il proprio campo ID univoco. Questa è la chiave primaria. Colleghiamo le tabelle utilizzando un valore di chiave primaria come chiave esterna in un'altra tabella. Maggiori informazioni su chiavi primarie e chiavi esterne.
Errore di database n. 2: incorporare una tabella in una tabella
Questo è un altro errore comune, ma non sempre risaltano tanto quanto i campi ripetitivi. Quando si progetta un database, si desidera assicurarsi che tutti i dati in una tabella si riferiscano a se stesso. È come il gioco di quel bambino per scoprire cosa è diverso. Se hai una banana, una fragola, una pesca e un televisore, il televisore probabilmente appartiene a qualcun altro.
Sulla stessa falsariga, se hai una tabella di venditori, tutte le informazioni in quella tabella dovrebbero riguardare specificamente quella persona di vendita. Qualsiasi informazione extra che non sia unica per quel venditore può appartenere da qualche altra parte nel tuo database.
| SalesID | Primo | Scorso | Indirizzo | Numero di telefono | Ufficio | OfficeNumber |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | fabbro | 504 2nd Street, New York, NY | (211) 122-1821 | New York (est) | (211) 855-4541 |
| 3 | Joe | Parrocchia | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Sebbene questa tabella possa sembrare che sia correlata al singolo venditore, in realtà ha una tabella incorporata nella tabella. Nota come Office e OfficeNumber si ripetono con "Austin Downtown". Cosa succede se cambia il numero di telefono dell'ufficio? Dovresti aggiornare un intero set di dati per una singola modifica di informazioni, che non è mai una buona cosa. Questi campi dovrebbero essere spostati nella propria tabella.
| SalesID | Primo | Scorso | Indirizzo | Numero di telefono | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | fabbro | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Parrocchia | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Ufficio | OfficeNumber |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (est) | (211) 855-4541 |
Questo tipo di design ti dà anche la possibilità di aggiungere ulteriori informazioni alla tabella Office senza creare un incubo di disordine nella tabella delle vendite. Immagina quanto lavoro sarebbe semplicemente tenere traccia dell'indirizzo, della città, dello stato e del codice postale se tutte quelle informazioni erano nella tabella delle vendite!
Errore di database n. 3: inserire due o più pezzi di informazioni in un singolo campo
L'incorporamento delle informazioni dell'ufficio nella tabella delle vendite personali non era l'unico problema con quel database. Il campo indirizzo conteneva tre informazioni: l'indirizzo, la città e lo stato. Ogni campo nel database dovrebbe contenere solo una singola informazione. Quando si hanno più informazioni in un singolo campo, può diventare più difficile interrogare il database per ottenere informazioni.
Ad esempio, cosa succede se volessimo eseguire una query su tutti gli addetti alle vendite di Austin? Dovremmo cercare all'interno del campo dell'indirizzo, che non è solo inefficiente, ma può restituire informazioni errate. Dopotutto, cosa succede se qualcuno vive in Austin street a Portland, in Oregon?
Ecco come dovrebbe apparire la tabella:
| SalesID | Primo | Scorso | Indirizzo 1 | Indirizzo 2 | Città | Stato | Cerniera lampo | Telefono |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | fabbro | 504 2nd St | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Parrocchia | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Ci sono un paio di cose da notare qui.Innanzitutto, "Indirizzo1" e "Indirizzo2" sembrerebbero cadere nell'errore di campi ripetitivi.
Tuttavia, in questo caso si riferiscono a dati separati che si riferiscono direttamente alla persona di vendita piuttosto che a un gruppo di dati ripetuto che dovrebbe andare nella propria tabella.
Inoltre, come errore bonus da evitare, nota come la formattazione per il numero di telefono è stata eliminata dal tavolo. Dovresti evitare di memorizzare il formato dei campi quando possibile. Nel caso di numeri di telefono, ci sono molti modi in cui le persone scrivono un numero di telefono: 215-555-5858 o (215) 555-5858. Ciò renderebbe più difficile la ricerca di un addetto alle vendite tramite il loro numero di telefono o una ricerca di venditori nello stesso prefisso.
Errore di database n. 4: non utilizzare una chiave primaria corretta
Nella maggior parte dei casi, si vorrà utilizzare un numero incrementale automatico o qualche altro numero generato o alfanumerico per la propria chiave primaria. Dovresti evitare di usare qualsiasi informazione reale per la chiave primaria, anche se suona come se fosse un buon identificatore.
Ad esempio, ognuno di noi ha il proprio numero di sicurezza sociale individuale, quindi l'utilizzo del numero di previdenza sociale per un database dei dipendenti potrebbe sembrare una buona idea. Ma mentre è raro, è possibile che anche un numero di sicurezza sociale cambi, e non vogliamo mai che la nostra chiave primaria cambi.
E questo è il problema con l'utilizzo delle informazioni reali come valore chiave. Può cambiare.
Errore di database n. 5: non utilizzare una convenzione di denominazione
Questo potrebbe non sembrare un grosso problema quando inizi a disegnare il tuo database, ma quando arrivi al punto di scrivere query sul database per recuperare informazioni, avere una convenzione sui nomi ti aiuterà a memorizzare i nomi dei campi.
Immagina solo quanto sarebbe più difficile quel processo se i nomi fossero memorizzati come FirstName, LastName in una tabella e first_name, last_name in un'altra tabella.
Le due convenzioni di denominazione più comuni sono in maiuscolo la prima lettera di ogni parola nel campo o separano le parole utilizzando un trattino basso. Potresti anche vedere alcuni sviluppatori capitalizzare la prima lettera di ogni parola tranne la prima parola: firstName, lastName.
Dovrai anche decidere di utilizzare nomi di tabelle singolari o nomi di tabelle plurali. È una tabella degli ordini o una tabella degli ordini? Si tratta di una tabella clienti o di clienti? Ancora una volta, non si vuole essere bloccati con una tabella Ordini e una tabella Clienti.
La convenzione di denominazione scelta non è importante quanto il processo di scelta effettiva e di adesione a una convenzione di denominazione.
Errore di database n. 6: indicizzazione impropria
L'indicizzazione è una delle cose più difficili da ottenere, specialmente per quelle nuove nella progettazione di database. Tutte le chiavi primarie e le chiavi esterne devono essere indicizzate. Queste sono le tabelle di collegamento insieme, quindi senza un indice, vedrai prestazioni molto scarse dal tuo database.
Ma quelli che troppo spesso mancano sono gli altri campi. Questi sono i campi "DOVE". Se si tende spesso a restringere la ricerca utilizzando un campo in una clausola WHERE, si vuole pensare a mettere un indice su quel campo. Tuttavia, non si desidera indicizzare eccessivamente la tabella, il che può anche influire negativamente sulle prestazioni.
Come decidere? Questo fa parte dell'arte del design del database. Non ci sono limiti rigidi sul numero di indici da inserire su un tavolo. In primo luogo, si desidera indicizzare qualsiasi campo che viene frequentemente utilizzato in una clausola WHERE. Ulteriori informazioni sull'indicizzazione corretta del database.
