Follow Us on Twitter

Coderen in de database, een doodzonde?

December 2005 - Binnen veel Java projecten wordt de database alleen gebruikt als een dataopslag. Dit terwijl in sommige situaties het gebruik van code in een database toegevoegde waarde kan hebben en zelfs noodzakelijk kan zijn.

In deze whitebook zal worden gekeken naar de principes van coderen in de database en hoe deze techniek binnen een J2EE architectuur past.

J2EE en de database

Veel Java programmeurs zien programmeren in de database als het doorbreken van de J2EE guidelines. Deze doelstellingen zijn: ontkoppeling, herbruikbaarheid en centralisatie. Hiermee wordt bedoeld dat applicaties zo opgezet moeten worden dat:

  • Componenten makkelijk vervangbaar moeten zijn door andere componenten zonder dat de hele applicatie verandert.
  • Componenten uitwisselbaar moeten zijn bij de bouw van applicaties en projecten.
  • Iedere functionaliteit maar één keer wordt gebouwd en niet wordt gedupliceerd in een ander component.

Binnen dit gedachtegoed is het gebruik van code in de database het verplaatsen van een component van de applicatie-tier naar de database-tier.

Figuur 1 - Component in zowel de applicatie als de database

 

Figuur 1 - Component in zowel de applicatie als de database

Zoals te zien in figuur 1 is het verplaatsen van een component van de applicatie naar de database volledig in lijn met het J2EE gedachtegoed, mits de code van het component niet op een andere plaats wordt gedupliceerd. Een van de redenen om code in de database te plaatsen is een garantie op data integriteit.

Data integriteit

Binnen projecten is het meestal funest als de database verkeerde gegevens bevat, zoals het ontbreken of teveel hebben van gegevens, gegevens die in een verkeerd formaat staan of gegevens die logischerwijs niet mogelijk zijn.

Dit kan voor een groot gedeelte worden opgelost in de database door constraints zoals primary keys, foreign keys of kolom types (b.v. een number of een varchar) te plaatsen of het verplicht stellen van een veld. Daarnaast kunnen aan de applicatie kant de bedrijfsregels, ook wel business rules genoemd, worden afgedwongen. Een voorbeeld van een business rule is dat als persoon A meedoet aan een levensloop regeling hij geen spaarloon mag hebben. Deze business rules zijn dus regels die bedrijfsbreed gelden voor gegevens en zijn afhankelijk van de industrie en het bedrijf.

Het checken van deze business rules gebeurt veelal in de applicaties, maar zodra er meerdere applicaties zijn die met dezelfde gegevens werken dan zal de implementatie van de business rules snel worden gedupliceerd. Een paar oplossingen hiervoor zijn modulair programmeren (component gebaseerd) en het hergebruik van componenten of een service oriented architectuur, waar alle applicaties via een servicelaag functioneren. Maar zelfs met een service oriented architecture is het niet gegarandeerd dat iemand met een database client of een vergeten applicatie data verandert in de database.

Figuur 2 laat een overzicht zien van een SOA met meerdere applicaties, één enkele database en het risico van losse legacy applicaties en/of database clients.

Figuur 2 - Data integriteit risico van een SOA met een legacy applicatie en een DB client
Figuur 2 - Data integriteit risico van een SOA met een legacy applicatie en een DB client

Zoals op figuur 2 te zien is, is de impact van een legacy applicatie of een database client binnen een application landscape zeer hoog als het gaat om data integriteit.

Het omgaan met situaties waar, mogelijk, één of meerdere applicaties op één database werken kan worden opgelost met code in de database. In het volgende gedeelte zal hier verder op worden ingegaan.

Coderen in de database

Het is in de huidige databases zeer eenvoudig en daarnaast ook zeer snel om code te hebben draaien in een database. Een stuk code in de database wordt een stored procedure genoemd. Oracle ondersteunt tegenwoordig standaard de Oracle taal PL/SQL en Java als implementatie talen van stored procedures. Stored procedures zijn stukken code die in de database zitten en in de database worden uitgevoerd.

Omdat er geen communicatie tussen een stored procedure en een database door middel van een netwerk nodig is, zijn stored procedures zeer snel en krachtig voor data intensieve operaties. Ook is het met stored procedures mogelijk om een stuk code uit te voeren als gegevens in de database worden gewijzigd, verwijderd of toegevoegd. De code die wordt aangeroepen als er wijzigingen plaatsvinden in de database wordt ook wel trigger genoemd.

Door het gebruik van code in de database is de probleemstelling zoals hierboven beschreven met betrekking tot data integriteit relatief eenvoudig op te lossen.

Figuur 3 - SOA architectuur met legacy applicatie en DB client met stored procedures
Figuur 3 - SOA architectuur met legacy applicatie en DB client met stored procedures

Als de business rules door middel van stored procedures in de database worden geplaatst, dan is het mogelijk om alle gegevens van alle applicaties die binnenkomen, ook degenen die buiten de service laag om gaan, te laten controleren door de business rules.

Conclusie

Is coderen in de database een doodzonde? Coderen in de database is zeker geen doodzonde. De mogelijkheid om de uitvoer van code op data te garanderen en de performance winst voor datacentrische operaties maakt dat deze optie zeker moet worden meegenomen als architecturele keuze.

 

Over de schrijver
Barre Dijkstra is een Java consultant met meer dan 7 jaar industrie ervaring en meer dan 5 jaar Java ervaring. Hij heeft ervaring met architectuur en implementatie van hoge volume J2EE applicaties in gedistribueerde omgevingen.

Deze whitebook is gebasseerd op de presentatie met de gelijknamige titel welke is gegeven door Barre Dijkstra op de NL-JUG JFall 2005.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.