Bedrijven moeten er dan ook voor waken dat de ontwikkelaar niet in een van de klassieke valkuilen stapt. Hier zijn de tien meest voorkomende fouten.

Fout 1: geen planning

De nummer 1 onder de fouten is volgens vicepresident van product management Deb Woods van Ingres het ontbreken van een adequate planning. Je kunt veel ellende voorkomen door alles van het begin af aan uit te stippelen. Meerdere factoren vereisen daarbij aandacht, zoals de keuze welk database-systeem in gebruik wordt genomen, hoe deze wordt gekoppeld aan de applicatie en het vaststellen van de eisen op het gebied van security en backup.

Fout 2: de verkeerde database kiezen

Databases verschillen onderling. Heeft die alles in zich dat je nodig hebt? Werkt hij met de juiste tools? De meeste leveranciers bieden een proof-of-concept demonstratie zodat bedrijven kunnen testen of al het benodigde wel aanwezig is.

Fout 3: de verkeerde hardware kiezen

Sommige databases werken prima op standaardhardware, maar anderen werken het beste op gespecialiseerde platformen. Kijk maar hoe Oracle samenwerkt met HP en later Sun om gespecialiseerde appliances te bouwen voor OLTP en applicaties voor datawarehousing, of naar de recente aankondiging van IBM rond PureScale. Die laatste is formeel niet met een appliance gebundeld, maar hij werkt exclusief op de IBM Power-servers.

Fout 4: geen goede documentatie bijhouden

Gebrek aan goede documentatie is niet alleen een probleem in de databasewereld, het speelt in alle vormen van programmatuur. Er zijn tal van voorbeelden te noemen waarbij het ontwikkelingsproces vertraging oploopt omdat programmeurs slecht gedocumenteerde code moesten complementeren, terwijl dat in het verleden al eens een keer is gebeurd. Het brengt geheid problemen als je veranderingen niet zorgvuldig wordt gedocumenteerd.

Fout 5: gebruik van bedrijfseigen taal-shortcuts

Het kan heel verleidelijk zijn om een bedrijfseigen taal te gebruiken in plaats van gewone SQL-code. Doe dat niet. Programmeurs winnen misschien 10 tot 15 minuten tijdens de ontwikkelingsfase, maar dat weegt op de lange termijn niet op tegen de licentie- en ontwikkelkosten. Woods van Ingres adviseert dan ook om het op SQL te houden, ook al gebruik je een bedrijfseigen database van Oracle, Sybase of IBM.

Fout 6: geen beheer van eventuele veranderingen

Applicaties groeien, en databases dus ook. Met veranderingen dient zorgvuldig omgesprongen te worden. Kleine wijzigingen kunnen een supersnelle functie omvormen tot een onooglijk langzaam gedrocht. Daarbij komt dat bedrijven bij aanpassingen aan applicatie en database maar al te vaak hun bedrijfsprocessen overboord moeten kieperen.

“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, netwerk-, telecom- en hostingbeheerder bij financiële instelling CPA Global en databaseontwikkelaar.

Fout 7: Extreme normalisatie van datastructuren

Een klassieke regel in database-ontwerp is dat de database zo veel mogelijk dient te worden genormaliseerd, zo stelde databasepionier Ted Codd ooit. Dat wil zeggen dat de structuur geschikt is voor querying en dat er geen foutjes voorkomen tijdens invoer, update en verwijdering. Maar Cartwright wijst erop dat dit in de praktijk te ver wordt doorgetrokken. Beheerders die erop staan om de datastructuren helemaal te normaliseren en dataduplictatie geheel willen uitbannen, kunnen er zeker van zijn dat ze de prestaties van bijna elke substantiële database neerhalen.

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. Dat wil niet zeggen dat de een perse beter is dan de ander. Databasebeheerders die zich hebben verdiept in de verschillende systemen weten dat wat optimaal is voor bijvoorbeeld Oracle 11 g, niet direct een goede zaak is voor Microsoft SQL Server.

Fout 9: Personeelsbezuinigingen

Ieder bedrijf dat serieus aan de slag wil met een database, moet bereid zijn om de juiste mensen ervoor aan te nemen, zegt David Cartwright. “Je zou denken dat een databasebeheerder en gekwalificeerde architect loeiend duur zijn. Maar het is nog veel duurder om semigekwalificeerd personeel aan te nemen en opgezadeld te worden met een database die kraakt en piept als je er een beetje load op zet.”

Fout 10: Bedrijfsverzuiling

Het is volgens Woods van Ingres ook van belang dat alle relevante onderdelen binnen het bedrijf samenwerken. Je kunt op de werkplek niet langer toe met verzuilde verhoudingen. Iedereen moet communiceren en over de schutting heen kijken. “Het meest kosteneffectief ben je als iedereen die belangen heeft in de database, van databasebeheerder tot ontwikkelaar, systeembeheerder en CIO, samenwerken”, zegt Woods.