Dingen die je moet weten over databases
Uit Yapf
Inhoud |
Mythes en andere onzin
Onzin: joins moet je voorkomen
Ik weet niet precies waar deze vandaan komt maar het schijnt erg populair te zijn onder beginners. Het idee is dat een query die een JOIN uitvoert onnodig traag is en dat je beter meerdere losse queries kunt draaien.
Dit is onzin, omdat het helemaal afhangt van de situatie. Ja een query zonder join doet minder werk, maar of dat trager is hangt helemaal af van hoeveel werk je zou moeten doen om de losse queries te draaien. Als de join 400ms duurt om 100 records op te halen, en de losse query 3ms per record, dan zou je denken dat je sneller af bent. Wat je daarbij niet moet vergeten is dat je die queries ook nog moet opstarten en verwerken en als dat per query 0.5ms duurt dan is de join dus veel sneller.
Relationele databases
Het woord relaties in de naam relationele databases staat er niet voor niets.
De gegevens die je opslaat hebben vrijwel altijd iets met elkaar te maken, ze horen bij elkaar. Denk bijvoorbeeld aan een winkel waarin elke bestelling altijd bij een klant hoort, of aan een forum waarbij elke post altijd bij een topic hoort en elk topic weer bij een forum.
Het zou bijzonder nogal raar zijn als je een bestelling zou kunnen invoeren voor een klant die niet bestaat want je kunt die bestelling niet meer uitleveren, je weet immers niet wie hem geplaatst heeft.
Relaties moet je afdwingen
De relaties kun je in de database afdwingen door een Primary-Key te maken in de tabel die aangeeft welke waarden toegestaan zijn en een Foreign-key te maken in de tabellen die naar die hoofdtabel verwijzen.
De tabel klanten bevat een Primary-key op klantnummer en de bestellingen heeft een kolom klantnummer die een Foreign-key bevat die verwijst naar klanten.
Waarom afdwingen in de database en niet in de applicatie?
Om een aantal redenen: 1. Omdat er geen betrouwbare manier bestaat om dit in een applicatie te doen. 2. Omdat een regel die in de database is afgedwongen nooit door een applicatie omzeilt kan worden, niet met opzet, niet per ongeluk, maar helemaal niet. 3. Omdat het bijzonder eenvoudig te doen is in de database terwijl het al snel erg complex wordt in de applicatie.
"Argumenten" tegen relaties in de database
Er zijn altijd mensen die vinden dat het afdwingen van relaties in de database geen goed idee is. De argumenten die gebruikt worden zijn vermakelijk...
"Wat is nou de kans dat het mis gaat?"
Het antwoord hierop is al kleurrijk beargumenteerd door Murphy & Campbell. Het komt neer op simpele kansrekening: Hoe vaker je iets doet wat een kleine kans heeft, hoe groter de totale kans wordt. Russische roulette is op hetzelfde gebaseerd.
Kortom: als het kan gebeuren dan zal het heus wel een keer gebeuren en naarmate het blangrijker wordt dat het *niet* gebeurt wordt de kans dat het gebeurt jist groter.
"Mijn script is zo geschreven dat het niet fout *kan* gaan!"
Assumption is the mother of all fuckups.
Afgezien van het feit dat je niet onfeilbaar bent en er dus altijd bugs kunnen zijn moet je niet vergeten dat er b.v. ook hackers bestaan die dingen proberen waar jij gewoon geen rekening mee hebt gehouden.
En denk eens een stap verder; wat als je server een stroomstoring krijgt en de databestanden van de database corrupt raken, dan kan het heel goed voorkomen dat er een paar records van sommige tabellen ontbreken. Als je relaties afdwingt in de database dan zal de database zelf merken dat er records ontbreken en maatregelen nemen.
Als je de relaties niet afdwingt dan kan de database elke tabel afzonderlijk wel repareren maar dan ontbreken er mogelijk records die in andere tabellen gebruikt worden. Volgens de database is elke tabel afzonderlijk in orde, maar je data klopt niet meer.
Ironisch genoeg is er maar één manier om te controleren of alles nog in orde is en dat is om queries te maken die de relaties alsnog controleren, inderdaad, die relaties die je niet in de database wilde aanmaken.
"Een tabel zonder relaties is veel sneller dan een tabel met relaties"
Een automonteur is ook veel sneller klaar met de apk als hij alleen hoeft te kijken of de motor nog wil starten, maar daarvoor breng je je auto niet naar de keuring.
Records kennen geen volgorde
Een van de veelgemaakte denkfouten in databases is dat je kunt sorteren op 'het id', waarbij 'id' staat voor de waarde van de primary key.
De waarde van de PK wordt vaak gevuld door middel van auto increment of een sequence, en die waarde loopt in de meeste gevallen netjes op zodat elk volgend record een waarde krijgt die één hoger is dan de vorige. Echter: dat is nietgegarandeerd (sequences kunnen een rollover krijgen, MySQL's auto inrement kan zichzelf resetten zodat hij weer bij een lager nummer begint.
Als je de wit sorteren op de invoervolgorde dan zul je de invoervolgorde moeten opslaan en dat is bijzonder eenvoudig te doen. Het enige wat nodig is is een kolom invoerdatum van het type datetime of timestamp, met een default waarde van NOW() of CURRENT_TIMESTAMP. Bij elke nieuwe insert zal de database zelf de huidige datum en tijd in die kolom zetten zodat je een echte invoervolgorde krijgt als je doet ORDER BY invoerdatum'.