Grensgebied van de ontwikkelaar

Door te werken met verschillende applicaties die gebruik maken van relationele databases, heb ik veel geleerd over hoe een applicatie zijn query opbouwt. Daarin is meestal wel iets te sturen, maar vaak niet genoeg. Soms is het dan ook efficiënter om een dergelijke applicatie te laten kijken naar een view, User Defined Function of Stored Procedure waarin de meeste complexiteit wordt gevangen. Omdat ik beide kanten heb ervaren, ben ik goed in staat de beste balans hierin te zoeken.

Vanuit deze ervaringen, wordt ik ook steeds vaker benaderd door applicatie ontwikkelaars. Voor programmeertalen als C#, Java, C++, GoLang en Swift bestaan mooie raamwerken die het leven voor een ontwikkelaar heel makkelijk maken. De applicatie ontwikkelaar hoeft vrijwel geen SQL te kennen, het raamwerk vertaalt de programmacode naar SQL. Hoewel zo’n raamwerk nog verassend goede queries kan genereren, zie ik toch nog steeds behoorlijk inefficiënte vraagstellingen terug in de database.

Door mijn kennis te combineren met die van de applicatie ontwikkelaar, lukt het meestal om samen de applicatie zodanig aan te passen dat een inefficiënte query wordt omgevormd naar een zeer efficiënte query. Met als resultaat lagere proces kosten, snellere resultaten en tevreden gebruikers. Soms is dat een kwestie van simpelweg de code in een andere volgorde te plaatsen en soms komt het neer op het schrijven van een database specifieke Stored Procedure of User Defined Function.   

Toch wordt slechte performance lang niet altijd veroorzaakt door slechte queries, maar door gebrek aan onderhoud. Vaak omdat de database is opgezet door ontwikkelaars in plaats van een DBA, soms door miscommunicatie tussen ontwikkelaars en DBA’s. Omdat ik beide kanten ken, ben ik in staat om snel de werkelijke oorzaak te vinden en weg te nemen. Soms door zelf geautomatiseerd onderhoud op te zetten, vaak door een brug te slaan tussen ontwikkelaar en DBA.