Of u nu werkt met een database met honderden records of miljoenen records, een goed databaseontwerp is altijd belangrijk. Niet alleen zal het het ophalen van de informatie veel gemakkelijker maken, het zal ook het uitbreiden van de database in de toekomst vereenvoudigen. Helaas is het gemakkelijk om in een paar valkuilen te vallen die het in de toekomst moeilijk kunnen maken.
Er zijn hele boeken geschreven over het normaliseren van een database, maar als je gewoon de veelgemaakte fouten die hier worden getoond, vermijdt, ben je op het goede spoor met een goed databaseontwerp.
Databasefout # 1: velden in een tabel herhalen
Een basis vuistregel voor een goed databaseontwerp is het herkennen van herhalende gegevens en het plaatsen van die herhalende kolommen in hun eigen tabel. Het herhalen van velden in een tabel is gebruikelijk voor degenen die afkomstig zijn uit de wereld van spreadsheets, maar terwijl spreadsheets over het algemeen plat van ontwerp zijn, moeten databases relationeel zijn. Het is alsof je van 2D naar 3D gaat.
Gelukkig zijn repetitieve velden meestal gemakkelijk te herkennen. Kijk maar eens naar deze tabel:
| Order ID | product1 | Product2 | product3 |
| 1 | Teddyberen | Snoepjes | |
| 2 | Snoepjes |
Wat gebeurt er als een bestelling uit vier producten bestaat? We zouden een nieuw veld aan de tabel moeten toevoegen om meer dan drie producten te ondersteunen. En als we een clienttoepassing rond de tafel hebben gebouwd om ons te helpen bij het invoeren van gegevens, moeten we deze misschien aanpassen met het nieuwe productveld. En hoe vinden we alle bestellingen met Jellybeans in de volgorde? We zouden genoodzaakt zijn om elk productveld in de tabel te ondervragen met een SQL-statement dat er als volgt uitziet: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OF Product2 = 'Jelly Beans' OF Product3 = 'Jelly Beans'.
In plaats van een enkele tabel te hebben die alle informatie samenvoegt, zouden we drie tabellen moeten hebben die elk een duidelijk stuk informatie bevatten. In dit voorbeeld willen we een tabel Orders met informatie over de bestelling zelf, een Products-tabel met al onze producten en een ProductOrders-tablet waarmee producten aan de bestelling zijn gekoppeld.
| Order ID | Klanten ID | Besteldatum | Totaal |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Product-ID | Artikel | tellen |
| 1 | Teddyberen | 1 |
| 2 | Snoepjes | 100 |
| ProductOrderID | Product-ID | Order ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Merk op hoe elke tabel zijn eigen unieke ID-veld heeft. Dit is de primaire sleutel. We koppelen tabellen door een primaire sleutelwaarde te gebruiken als een externe sleutel in een andere tabel. Meer informatie over primaire sleutels en externe sleutels.
Databasefout # 2: een tabel in een tabel insluiten
Dit is een andere veelgemaakte fout, maar deze valt niet altijd even duidelijk uit als repetitieve velden. Bij het ontwerpen van een database wilt u ervoor zorgen dat alle gegevens in een tabel op zichzelf betrekking hebben. Het is net als het spel van dat kind om te ontdekken wat anders is. Als je een banaan, een aardbei, een perzik en een televisie hebt, hoort de televisie waarschijnlijk ergens anders.
In dezelfde zin geldt dat als u een tabel met verkopers hebt, alle informatie in die tabel specifiek betrekking moet hebben op die verkoper. Alle extra informatie die niet uniek is voor die verkoper, kan ergens anders in uw database thuishoren.
| SalesID | Eerste | Laatste | Adres | Telefoonnummer | Kantoor | Kantoor nummer |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | smid | 504 2nd Street, New York, NY | (211) 122-1821 | New York (Oost) | (211) 855-4541 |
| 3 | Joe | Parochie | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Hoewel deze tabel eruit zou kunnen zien alsof deze allemaal gerelateerd is aan de individuele verkoper, heeft deze een tabel die is ingesloten in de tabel. Merk op hoe het Office en OfficeNumber herhalen met "Austin Downtown". Wat als een telefoonnummer op een kantoor verandert? Je zou een hele set gegevens moeten updaten voor een enkel stuk informatie dat verandert, wat nooit een goede zaak is. Deze velden moeten naar hun eigen tabel worden verplaatst.
| SalesID | Eerste | Laatste | Adres | Telefoonnummer | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | smid | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Parochie | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Kantoor | Kantoor nummer |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (Oost) | (211) 855-4541 |
Dit type ontwerp biedt u ook de mogelijkheid om extra informatie aan de Office-tabel toe te voegen zonder een nachtmerrie van rommel te creëren in de tabel met verkopers. Stel je voor hoeveel werk het zou zijn om gewoon het straatadres, de stad, de staat en de postcode bij te houden als al die informatie in de tabel met verkopers stond!
Databasefout # 3: twee of meer stukjes informatie in één veld plaatsen
Het insluiten van de kantoorinformatie in de verkooppersoonentabel was niet het enige probleem met die database. Het adresveld bevatte drie stukjes informatie: het straatadres, de stad en de staat. Elk veld in de database mag slechts één stuk informatie bevatten. Wanneer u meerdere gegevens in een enkel veld hebt, kan het moeilijker worden om de database om informatie te vragen.
Wat als we bijvoorbeeld een vraag wilden stellen aan alle verkopers uit Austin? We zouden moeten zoeken in het adresveld, wat niet alleen inefficiënt is, maar ook slechte informatie kan retourneren. Wat gebeurt er tenslotte als iemand op Austin Street in Portland, Oregon woonde?
Dit is hoe de tabel eruit zou moeten zien:
| SalesID | Eerste | Laatste | Adres 1 | Adres 2 | stad | Staat | ritssluiting | Telefoon |
| 1 | Sam | Elliot | 118 Hoofdst | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | smid | 504 2e straat | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Parochie | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Er zijn een paar dingen om op te merken hier.Ten eerste lijken "Adres1" en "Adres2" te vallen onder de fout van herhaalde velden.
In dit geval verwijzen ze echter naar afzonderlijke stukjes gegevens die rechtstreeks betrekking hebben op de verkoper, in plaats van een zich herhalende groep gegevens die in de eigen tabel moet worden opgenomen.
Houd ook, als een bonusfout te vermijden, op hoe de opmaak van het telefoonnummer uit de tabel is gestript. Vermijd het opslaan van het formaat van velden als dat enigszins mogelijk is. In het geval van telefoonnummers zijn er meerdere manieren waarop mensen een telefoonnummer schrijven: 215-555-5858 of (215) 555-5858. Dit zou het zoeken naar een verkoopmedewerker op hun telefoonnummer of het zoeken naar verkopers in hetzelfde netnummer bemoeilijken.
Databasefout # 4: geen juiste primaire sleutel gebruiken
In de meeste gevallen wilt u een automatisch oplopend nummer of een ander gegenereerd nummer of alfanumeriek gebruiken voor uw primaire sleutel. U moet voorkomen dat u feitelijke informatie voor de primaire sleutel gebruikt, zelfs als het klinkt alsof het een goede identificatie is.
We hebben bijvoorbeeld elk een eigen burgerservicenummer, dus het gebruik van het sofinummer voor een werknemersdatabase klinkt misschien als een goed idee. Maar hoewel het zeldzaam is, is het mogelijk dat zelfs een sofinummer verandert en we willen nooit dat onze primaire sleutel verandert.
En dat is het probleem met het gebruik van feitelijke informatie als een belangrijke waarde. Het kan veranderen.
Databasefout # 5: geen benamingconventie gebruiken
Dit klinkt misschien niet als een grote deal wanneer je voor het eerst aan de slag gaat met het ontwerpen van je database, maar als je eenmaal het punt hebt bereikt om vragen tegen de database te schrijven om informatie op te halen, kan een naamgevingsconventie helpen bij het onthouden van veldnamen.
Stel je eens voor hoe moeilijk dat proces zou zijn als namen zouden worden opgeslagen als FirstName, LastName in één tabel en first_name, last_name in een andere tabel.
De twee populairste naamconventies zijn het hoofdlettergebruiken van de eerste letter van elk woord in het veld of het scheiden van woorden met behulp van een onderstrepingsteken. U kunt ook zien dat sommige ontwikkelaars de eerste letter van elk woord kapitaliseren, behalve het eerste woord: firstName, lastName.
U zult ook willen beslissen over het gebruik van enkelvoudige tabelnamen of meerdere tabelnamen. Is het een bestellijst of een tabel met bestellingen? Is het een klantentabel of een klantentafel? Nogmaals, u wilt niet vastzitten aan een tabel met bestellingen en een tabel met klanten.
De naamgevingsconventie die u kiest, is niet zo belangrijk als het proces van het feitelijk kiezen en vasthouden aan een naamgevingsconventie.
Databasefout # 6: onjuiste indexering
Indexeren is een van de moeilijkste dingen om goed te krijgen, vooral voor degenen die nieuw zijn in databaseontwerp. Alle primaire sleutels en externe sleutels moeten worden geïndexeerd. Dit zijn de linktabellen samen, dus zonder een index, zult u zeer slechte prestaties uit uw database zien.
Maar wat te vaak wordt gemist, zijn de andere velden. Dit zijn de velden "WHERE". Als u uw zoekopdracht vaak wilt verfijnen door een veld in een WHERE-component te gebruiken, wilt u erover nadenken een index op dat veld te plaatsen. U wilt de tabel echter niet overdreven indexeren, wat ook de prestaties kan schaden.
Hoe te beslissen? Dit maakt deel uit van de kunst van databaseontwerp. Er zijn geen harde limieten voor het aantal indexen dat u op een tabel moet zetten. U wilt in de eerste plaats elk veld indexeren dat veel wordt gebruikt in een WHERE-component. Lees meer over het correct indexeren van uw database.
