Net zo snel zoeken als in Google? 3 tips bij het ontwikkelen van een database-applicatie

Verwondert het jou ook? Jouw huidige telefoon heeft meer geheugen en rekenkracht dan jouw desktop van tien jaar geleden. Je zou denken dat het in het huidige technologische tijdperk geen enkel probleem meer is om applicaties voor ingewikkelde business-vraagstukken in de agrofoodsector te bouwen die altijd een snelle respons geven. Maar dat blijkt in de praktijk toch anders te zijn. Hoe komt dat? En waar moet je rekening mee houden als je een betrouwbare database-applicatie wilt ontwikkelen?

1. Applicaties hebben een rijkere interface

Applicaties worden steeds gebruiksvriendelijker. In de eerste NS-reisplanner moest je de exacte spelling weten van station Ede-Wageningen. Nu krijg je bij elke toetsaanslag een aangepaste lijst met suggesties. Dat maakt het gebruik een stuk makkelijker, maar het levert ook een spervuur aan zoekopdrachten op. De database heeft het dus veel drukker dan vroeger.

2. Minder inzet van data-specialisten

De hulpmiddelen waarmee deze rijkere applicaties worden gemaakt, zijn logischerwijs complex. Ontwikkelaars worden tegenwoordig vooral opgeleid in het juiste gebruik van die ingewikkelde tools; het efficiënt opzetten van zoekopdrachten in de database, is steeds minder een aandachtspunt.

Sterker nog: het onttrekt zich steeds meer aan het zicht van de ontwikkelaar. Veel gebeurt automatisch en vaak niet op de efficiëntste manier, maar dankzij krachtigere hardware kan men zich dat permitteren. Data-specialisten — engineers die gespecialiseerd zijn in het handig en efficiënt benaderen van data — zijn schaars geworden. Vaak worden ze pas later ingeschakeld, als er problemen ontstaan in het gedrag van de applicatie. Ze kunnen monitoren wat er aan zoekopdrachten door de database wordt uitgevoerd. Vaak komt dan pas aan het licht hoe onhandig die zoekopdrachten zijn opgebouwd.

3. Het applicatieontwerp is minder data-georiënteerd

Wat eigenlijk nog erger is: niet alleen in de bouwfase, maar ook in de ontwerpfase gaat het fout. Engineers denken dat het, door alle ontwikkelingen, minder noodzakelijk is om kritisch te zijn op het ontwerp van een applicatie. De capaciteit van de rekenkracht, het geheugen en de snelheid van de netwerken is zo onvoorstelbaar sterk gegroeid, je krijgt toch alleen maar problemen als je gekke dingen doet?!

Toch is dat niet zo. Hardware-capaciteit is geen roomijs, waarvan “meer” al vrij snel “genoeg” betekent. Denk eerder aan een krantenjongen: zelfs als hij zijn fiets inruilt voor een Ferrari is hij niet blij met de opdracht “voortaan ga jij alle kranten bezorgen in een straal van 100km”

Die opdracht zal ontvangen worden als een slecht idee, maar het illustreert perfect hoe gemakkelijk het is om een rampzalig applicatie-ontwerp te maken, hoe sterk de capaciteit van hardware ook blijft groeien. Meestal denken engineers veel te beperkt na over de opzet van de applicatie, de data-structuur en de toekomstige performance.

4. Google versterkt de misverstanden

Het misverstand dat je nonchalant mag omgaan met data-access (het ophalen van data uit een database vanuit een applicatie) wordt misschien in de hand gewerkt door Google. Veel mensen denken dat Google in 0,33 seconden “het hele internet doorzoekt” om te concluderen dat er 6.030.000 pagina’s zijn waar bijvoorbeeld Q-ray wordt genoemd.

De neiging om zich te spiegelen aan Google is zo hardnekkig, dat het me de moeite waard lijkt om iets uitgebreider te illustreren waar de vergelijking van een business-applicatie met Google mank gaat.

Voorbeeld 1 – een eenvoudig praktijkgeval: een boeken webshop 
Zo’n webshop zou redelijk eenvoudig kunnen zijn: titel, schrijver, categorie, prijs, etc. Zoeken gaat eenvoudig en snel.

Voorbeeld 2 – een ingewikkelder praktijkgeval: online handel in versproducten
Bij versproducten fluctueert de aanvoer en zijn de prijzen variabel, afhankelijk van de samenstelling van de bestelling, de afgenomen hoeveelheid, de manier en de plaats van levering. Er zijn talloze kenmerken waarmee het product wordt beschreven. Als je zoekmogelijkheden wilt aanbieden op alle kenmerken en eigenschappen, worden de zoekvragen behoorlijk ingewikkeld. Dat legt meer gewicht in de schaal dan we ons misschien realiseren.

Daarom zullen we aan de hand van twee analogieën eens een denkbeeldige wedstrijd doen met Google.

Analogie 1: de eenvoudige variant
Wie oud genoeg is, kent misschien nog de meter aan telefoonboeken, die vroeger op het postkantoor ter inzage lag. Op de vraag: “geef me het telefoonnummer van Karel Jansen, aan de Eendrachtlaan in Leidschendam”, is het antwoord razendsnel te vinden: je pakt het deel Zuid-Holland, de plaatsen zijn alfabetisch gerangschikt, en daarbinnen de achternamen ook. Je scheurt snel de juiste pagina eruit en rent ermee over de finish-lijn: jawel, bijna die 0.33 seconden van Google geëvenaard!

In essentie is een willekeurige Google-zoekvraag natuurlijk niet moeilijker dan de zoekactie in het telefoonboek. Als je wilt weten welk woord te vinden is op welke internetpagina, hou je gewoon een lijst bij. Een heel grote lijst, dat wel, maar het server-park van Google is daarop afgestemd.

Analogie 2: de complexere variant
Als we de opdracht ingewikkelder maken, wordt het voor ons lastiger om uit te voeren, maar misschien voor Google ook:

Geef de verschillende voornamen en bijbehorende aantallen mensen in Zuid-Holland die in 2012 zijn geopereerd aan hun linkerknie, een kleinkind hebben met de naam Iris dat blond haar heeft en blauwe ogen, twee konijnen heeft die ze samen met haar halfbroertje verzorgt en die in een twee-onder-een-kap woning wonen met een tuin van minstens 150 vierkante meter. Ik wil de lijst graag zien op volgorde van afnemende aantallen.

OK! Hoe lang gaat het duren om dat uit te zoeken? Het lijkt inderdaad haast onbegonnen werk. Met alleen een telefoonboek kom je er niet. Zullen we de leegstaande V&D volzetten met extra versies in andere sorteringen? Of helpt ook dat ons uiteindelijk niet verder?

In business-applicaties beland je vroeg of laat in deze graad van complexiteit. Om te beoordelen wat de beste aanpak is om zoekvragen voldoende snel te kunnen beantwoorden en wat je je wel en niet kunt permitteren bij het ontwerp vergt de nodige expertise.

3 tips bij het ontwikkelen van een betrouwbare database-applicatie

Om zoekopdrachten snel te kunnen uitvoeren gelden bij het ontwikkelen van database-applicaties de volgende tips:

1. Besteed naast applicatie-ontwerp voldoende aandacht aan database ontwerp.
2. Laat tijdig monitoring uitvoeren op het gebruik van de database.
3. Inzet van data-specialisten voorkomt latere problemen

Wil je weten hoe je de database-applicatie van jouw organisatie kunt verbeteren of wat de mogelijkheden van zo’n applicatie voor de business kan betekenen om performance, datakwaliteit en betrouwbaarheid te waarborgen? Neem vrijblijvend contact met ons op. Onze specialisten vertellen u er graag meer over.