10 grootste fouten bij database-ontwikkeling

Databases blijven een vak apart en daarvoor zijn dus gespecialiseerde mensen nodig. Ik merk vaak dat een database ontwerp er 'even bij gedaan wordt'. Niet altijd even verstandig, al hangt dat sterk af van het doel, verwachtte load, systeem, disk ruimte, soort hardware en andere parameters, maar net als voor alles geldt, iedereen zijn vak, je kan niet alles weten.

Ik weet aardig wat van databases, maar ga mij niet vragen een high performance database op te zetten die een load van 1500 connections kan verwerken met een data load van enkele gigabytes per uur. (Noem maar wat) En dan ook nog secure etc etc.

Het zijn wel inkoppers, deze 'tips', maar op netjes op rijtje heeft wel zijn nut. Op sommige punten valt wel wat af te dingen ook, maar enig verschil van inzicht is niet erg.

Vervelender vind ik is dat helaas onzorgvuldig met terminologie wordt omgesprongen, zo wordt enkele malen het woord Database gebruikt terwijl DBMS (Database Management System) wordt bedoeld. Dit maakt het voor (vooralsnog) minder ingeweiden verwarrend, terwijl die lijst juist voor die groep bedoeld is.

Fout 2: de verkeerde database kiezen Fout 8: Elke database op dezelfde manier benaderen

Hoewel databases volgens dezelfde principes werken met SQL-queries en dezelfde structuren kennen, moet je toch beseffen dat ze van elkaar verschillen.Wel een beetje komisch. Fout 11: denken dat er niet meer is dan alleen relationele databases. Het gaat niet alleen om legacy, al kan je SQL embedden in COBOL, maar ook om andere vormen van databases. Via Slashdot kwam ik van de week op deze blogpost terecht.

Dit is nog eens nieuws.

Open deuren nog verder open schoppen is ook knap!

De helft van deze punten is ook van toepassing op het bouwen van de Eiffeltoren, Het uitvoeren van een maanreis en elke andere aktiviteit die de inzet van een groter team vergt.

“Ik heb het recent meegemaakt dat het systeem in eerste instantie een bug leek te hebben, maar dat het bedrijf het eigenlijk verkeerd had geconfigureerd waardoor het inging tegen een eerder gedefinieerde preconditie. Dat conflicteerde met een van de sleutelparameters van de gehele database-architectuur, waardoor het systeem onvoorspelbare resultaten terugstuurde”, zegt David Cartwright

Hahaha... dit is van het kaliber 'ik had een sterretje in mijn voorruit en toen ging het vriezen en toe zei ie krak en toen belde ik een meneer en die zette er toen een nieuwe ruit in en toen ging ik weer lachen'.

Als-je-blieft. Zeg dan niks ;)

Geneuzel van een stagiare die niet weet dat alles in de helft van de tijd moet gebeuren.

Ook in het onderdeel hoe-zet-je-een-database-met-gegevens-op gaat nog al eens wat vaak mis.

Een voorbeeld is de database van Vektis, een semi-overheidsinstantie die de registratie en administratie moet stroomlijnen voor de zorg.

Men heeft bijvoorbeeld bij het aanmaken van de groep psychologen er voor gekozen dat nummers vaker gebruikt mogen worden met het enige onderscheid dat praktijken van psychologen 1 nul minder heeft staan in het nummer. Bijvoorbeeld psycholoog A heeft AGB-code 94000012 en praktijk B AGB-code 9400012. Een digibeet kan zelfs zien dat hier fouten in gaan ontstaan bij het handmatig invoeren in formulieren en andere systemen en dat is dus ook gebeurt.
Als Vektis gekozen had voor een onderscheid met misschien een letter of een ander cijfer dan was het onderscheid een stuk duidelijker.

Het mag duidelijk wezen dat Vektis deze fout niet wil/kan inzien.

Dit soort artikelen hoeft voor mij echt niet hier. Als ik wat wil weten over database design dan ga ik niet naar webwereld. Daar verwacht ik nieuws. Geen oppervlakkige lul-specialtjes vol sluikreklame.

@Lennard, toch biedt een artikel als deze wel de ruimte om er een discussie over te starten.

Ik ben een analist binnen een groot telecombedrijf en weet maar al te goed hoe slechte databases tot slechte performance zullen leiden. Mijn 'leven' bestaat uit het analyseren van data en het presenteren van cijfers en doe op basis van mijn bevindingen ook voorspellingen.

Een jaar geleden is er een ommekeer gekomen in de manier waarop data kon worden gepresenteerd en becijferd, hiertoe werd er een webbased schil gelegd om een te grote Oracle-database.

3/4 jaar doe ik er al over om alleen al te begrijpen hoe de structuren in elkaar steken en sinds kort heb ik toegang tot de database zelf. Aan de hand van onze bedrijfsmodellen heb ik noodgedwongen de wijze waarop wij onze gegevens willen zien nagebootst in query's en wel op een manier die ikzelf verafschuw.

Mijn grootste nachtmerrie is een tabel die zoveel informatie probeert te vangen vanuit meerdere bronnen terwijl er meerdere miljoenen records in staan. Mijn nachtmerrie is geen materie meer die alleen in de slaap voorkomt, ik heb hier dagelijks mee te maken.

Het kost zeer veel tijd om deze data te beheersen terwijl ik analist ben. Ik moet mij niet bezig willen houden met een database, deze moet goed gebouwd en onderhouden worden. Bedrijven kunnen veel willen maar stellen onrealistische eisen in sommige gevallen. Zelfs zo onrealistisch dat de eigen processen eraan onderdoor dreigen te gaan.

Tegenwoordig heb ik een vaste dag met een database-engineer ingeroosterd waarbij wij kijken naar zwakke plekken, dat is kolder ende waanzin maar jammerlijk onmisbaar.

Voor mij is de kern, en dat geldt ook voor andere onderwerpen, dat door bezuinigingen en uitspraken als: ICT is toch als water uit de kraan, niet voldoende gekwalificeerd personeel wordt aangenomen met een groeimogelijkheid die amper boven secretaresse-niveau uitkomt, waardoor we opgezadeld worden met een database die kraakt en piept als je er een beetje load op zet en dagen offline is na een virusincident.

Heb niks gelezen over het meest voorkomende en vertragende probleem dat ik in zo'n beetje elke database weer tegenkom:

Missende/incomplete/incorrecte indexes!!!

volledig uitnormaliseren is indd. niet altijd evenhandig en maakt queries vaak overdreven lang en omslachtig.
Toch als je maar de juiste indexes aanmaakt valt er meestal binnen een redelijke request tijd nog wel een resultaatje uit te halen.