[Alg] Business Logic in de database

[whoami]

Ik vraag me af hoe jullie er tegenover staan: BL die in Stored Procedures en triggers zit.

Zelf ben ik er geen voorstander van, echter, op m'n werk wordt het wel soms zo gedaan.
Het heeft zo z'n voor- en nadelen: de logica wordt op de server uitgevoerd en daardoor kan het wel eens sneller zijn.

Ik vind echter dat de BL nogal eens een soep kan worden als die verspreid staat over stored procedures en triggers. Stel dat je een stuk BL moet aanpassen: dan ga je je SP's gaan aanpassen, maar moet je ook nog de triggers gaan bekijken, ervoor zorgen dat die 2 goed samenwerken, etc....
Stel dat de BL in het DBMS vervat zit dmv SP's en triggers, en dat er beslist wordt om naar een ander DBMS over te stappen, dan mag je ook nog eens alle BL porten...

Waar hoort de BL volgens jullie thuis? In de DB, of op de client?

[Nexopheus]

SP en triggers zijn toch gewoon een integraal onderdeel van de DL ? Je DAL levert de interface naar de BL. Of de SP en triggers dan ook BL zijn?? mmm blijft lastig.

[ Voor 23% gewijzigd door Nexopheus op 12-07-2003 10:30 ]

[Annie]

whoami schreef op 12 July 2003 @ 10:10:
Ik vind echter dat de BL nogal eens een soep kan worden als die verspreid staat over stored procedures en triggers. Stel dat je een stuk BL moet aanpassen: dan ga je je SP's gaan aanpassen, maar moet je ook nog de triggers gaan bekijken, ervoor zorgen dat die 2 goed samenwerken, etc....

Hmm, heel sterk vind ik dit argument niet. Met goede documentatie kom je een heel eind. Bovendien kan de BL in een client ook onoverzichtelijk geimplementeerd zijn.

whoami schreef op 12 July 2003 @ 10:10:
Stel dat de BL in het DBMS vervat zit dmv SP's en triggers, en dat er beslist wordt om naar een ander DBMS over te stappen, dan mag je ook nog eens alle BL porten...

Ook dit is imho geen heel erg overtuigend argument. Wat als de client op een ander OS moet komen? Dan moet je alle BL ook meeporten (extra werk). Wat als andere systemen ook gebruik moeten maken van je database dan moet daar de BL ook los voor ontwikkeld worden.

whoami schreef op 12 July 2003 @ 10:10:
Waar hoort de BL volgens jullie thuis? In de DB, of op de client?

Ik neig sterk naar de DB, maar een eenduidig antwoord is denk ik niet te geven (of ik durf het gewoon niet ). Ik denk dat het gewoon in elke situatie een afweging/inschatting moet zijn van de voor- en nadelen.

[whoami]

Inderdaad, er is voor beide manieren wat te zeggen.

Annie schreef op 12 July 2003 @ 10:51:
Ook dit is imho geen heel erg overtuigend argument. Wat als de client op een ander OS moet komen? Dan moet je alle BL ook meeporten (extra werk). Wat als andere systemen ook gebruik moeten maken van je database dan moet daar de BL ook los voor ontwikkeld worden.

Mijn verwoording van 'BL op de client' was misschien niet zo goed. Je kan namelijk je business logic (die geschreven is in een taal ala C#, Java, ....) ook ergens centraal houden. Denk maar aan webapps, application servers, etc...

[Anoniem: 3057]

Eerlijk gezegd ben ik ook geen voorstander van BL in SP. Hoewel je met documentatie een heleboel van de daardoor ontstane onduidelijkheid kan opheffen, creeer je toch wel extra uitdagingen voor het maken van aanpassingen. Bij een aanpassing die zowel SP als externe BL raakt, moet de documentatie ook weer aangepast worden. Geen probleem, zo lijkt het, maar hoe groter de aanpassing, hoe groter de kans op fouten. Kortom, de overhead en risico's van een dergelijke aanpassing is relatief groot.

Als je kiest geen BL in SP's op te nemen, heb je mijns inziens twee grote nadelen:
1) Business Logic code is complexer, omdat de kracht van SP's in een database niet gebruikt kan worden. Hierdoor zal voor dezelfde functionaliteit meer regels code ontstaan.
2) Performance zal lijden, aangezien BL in SP's veel sneller zal werken dan in een aparte BL laag. Er zal meer data opgehaald moeten worden uit de DB naar de BL laag, en daar zal de verwerking relatief langzaam zijn.

Als je deze twee nadelen in de gaten houdt, zal je specifiek kunnen kiezen waar het zinvol is om alsnog BL in je SP's te gebruiken. Aan de andere kan zijn de twee nadelen deels op te lossen:
ad 1) Deel je Business Logic verder op in data transformatie en business rules delen, zodat je de code wel binnen eenzelfde laag houdt, maar wel gestructureerd op een manier waardoor je later alsnog BL in SP's kunt zetten, en de code beter onderhoudbaar blijft
ad 2) Veel performance problemen zijn op te lossen door de hardware configuratie en tuning aan te passen op de werking van de applicatie. Een stevige DB server, een snelle verbinding naar de application server, en een applicatie architectuur waarbij de BL laag is uit te spreiden over meerdere app servers.

Er is geen goede, universele oplossing. Zolang je de voor- en nadelen bij iedere beslissing voor jouw project naloopt, zal je de beste oplossing voor de specifieke situatie vinden. Leg dergelijke beslissingen en de motivatie wel vast, zodat later bij wijzigingen dit opnieuw geevalueerd kan worden.

[alienfruit]

Momenteel gebruik ik alleen SP's in DBMS om de consistentie van de gegevens in de database correct te houden. Dit vind ik _zelf_ niet vallen in de Business Logic kader.

[Database freak]

De database kernel kan, als de BL d.m.v. SP en triggers geimplementeerd is, vedere uitvoer van veel transacties optimaliseren, omdat ie weet welke restricties en vervolg acties moeten worden uitgevoerd. Als de BL in de client of middle ware server zich bevindt kan dat niet; de db kernel krijgt dan achter elkaar losse transacties die die min of meer synchroon gaat uitvoeren. Daarnaast vindt er elke keer een 'handshakking' plaats tussen de client/middleware server en de db-server, waarmee veel kostbare tijd gemoeit is. De efficiency die je hiermee verliest kan wel een factor 10 of meer zijn; wil je dat met hardware oplossen dan zal je diep in buidel moeten tasten.
Mijn advies zou zijn, heb je een systeem met relatief weinig transacties (of weinig complexe transacties) en is de BL omvangrijk, stop het dan maar in de client/middleware; het performance-voordeel weegt dan niet op tegen het onderhoud.
Krijgt het systeem in productie veel (complexe) transacties en moet het verder door kunnen schalen; stop de BL in de DB.
Microsoft is momenteel bezig een oplossing te maken voor dit dilema. In de volgende versie van SQL Server (Yukon) zal VB.net C#.net en een aantal andere talen, naar transact-SQL in de database kernel zelf geimplementeerd worden. Hierdoor kan je met een onderhoudbaardere programeer-omgeving toch de performance voordelen van een database programmeer taal behalen. Er komt een Beta eind deze zomer hiervan uit.

[whoami]

alienfruit schreef op 12 July 2003 @ 12:36:
Momenteel gebruik ik alleen SP's in DBMS om de consistentie van de gegevens in de database correct te houden. Dit vind ik _zelf_ niet vallen in de Business Logic kader.

Wat versta je daar dan onder? Je hebt toch andere mogelijkheden om de consistentie van je gegevens te garanderen? Rules, Checks, etc...

[Alarmnummer]

Business Logic hoort zeker niet in de db thuis, mensen die dat zeggen zijn prutsers 1e klas. Business logic hoort eigelijk niet eens in de applicatie thuis, maar kan het beste extern aangesloten worden dmv rules. Hierdoor zal bedrijfs logica niet niet versleuteld worden in de code (en ook niet in de db) maar valt extern te configureren. En aangezien business logic typisch iets is dat veel veranderd, kan je hier uitstekend zonder hercompilatie ed mee uit de voeten. Voor een uitstekend boek hierover zie:

Business Rules Applied: Building Better Systems Using the Business Rules Approach - by Barbara Von Halle

[ Voor 12% gewijzigd door Alarmnummer op 12-07-2003 13:41 ]

[EfBe]

whoami schreef op 12 July 2003 @ 10:10:
Waar hoort de BL volgens jullie thuis? In de DB, of op de client?

Heb ik de keuze tussen de DB en de client? Dan kies ik voor de DB

Maar zonder gekheid: het boeit niet zo waar de BL zit. Men moet niet zo krampachtig doen over n-tier development. Je ziet mensen witheet worden wanneer je zegt dat je een DAL en een BL Facade samenvoegt of bv geen BL layer tussen je gui en DAL plaatst, en dan denk ik "waar maak je je druk om? Het is een abstract concept, geen vaste set rules".

Zoals met alle code in een systeem, en zeker in een distributed systeem, moet deze voldoen aan vooraf gestelde eisen. Als er alleen een eis is dat het bloedsnel moet zijn, kun je dus alleen aan de performance geen consessies doen maar aan alle andere aspected zoals onderhoudbaarheid wel. Veelal echter stelt men de eis dat het ook onderhoudbaar moet zijn en dat er consessies gedaan mogen worden mbt de snelheid. Je komt dan snel uit op het plaatsen van business logic buiten het RDBMS want logisch gezien is de BL layer een data consumer, en niet onderdeel van de data producer, wat dus de layer is pal op de tables/views.

Op zich maakt het dus niet zoveel uit waar je je BL plaatst, het hangt puur af welke eisen er aan je code worden gesteld en of je die met de keuze die je maakt waar je je BL plaatst ook waarmaakt. Ik weet uit ervaring dat onderhoudbaarheid bij BL in bv T-SQL niet echt hoog is (dwz, je moet meer moeite doen om dezelfde hoeveelheid onderhoudbaarheid te halen dan wanneer je BL code in classes bouwt bovenop een DAL / BLFacade), maar snelheid wel des te meer.

[EfBe]

Alarmnummer schreef op 12 July 2003 @ 13:39:
Business Logic hoort zeker niet in de db thuis, mensen die dat zeggen zijn prutsers 1e klas. Business logic hoort eigelijk niet eens in de applicatie thuis, maar kan het beste extern aangesloten worden dmv rules. Hierdoor zal bedrijfs logica niet niet versleuteld worden in de code (en ook niet in de db) maar valt extern te configureren. En aangezien business logic typisch iets is dat veel veranderd, kan je hier uitstekend zonder hercompilatie ed mee uit de voeten.

Dan praat je niet over 'logic' maar over stuurparameters waarmee de 'logic' werkt. Als je BL analyseert zie je dat de processen veelal hetzelfde werken, maar met verschillende input parameters en stuurfactoren andere resultaten opleveren. Het is dan natuurlijk zaak die stuurfactoren en de input parameters flexibel te houden zodat je de processen kunt sturen door het 'tweaken' van de input parameters.

Is al oud concept, en tot kunst verheven door de ERP boys.

[whoami]

EfBe schreef op 12 July 2003 @ 14:20:
[...]

Maar zonder gekheid: het boeit niet zo waar de BL zit. Men moet niet zo krampachtig doen over n-tier development. Je ziet mensen witheet worden wanneer je zegt dat je een DAL en een BL Facade samenvoegt of bv geen BL layer tussen je gui en DAL plaatst, en dan denk ik "waar maak je je druk om? Het is een abstract concept, geen vaste set rules".

Idd, je hebt hier zeker een punt. Het is onzin om aan regeltjes vast te houden als je bepaalde dingen kunt verbeteren/versnellen door even van die regels af te wijken. (Ik denk dat dit trouwens al eens behandeld geweest is in dit topic.

Zoals met alle code in een systeem, en zeker in een distributed systeem, moet deze voldoen aan vooraf gestelde eisen. Als er alleen een eis is dat het bloedsnel moet zijn, kun je dus alleen aan de performance geen consessies doen maar aan alle andere aspected zoals onderhoudbaarheid wel. Veelal echter stelt men de eis dat het ook onderhoudbaar moet zijn en dat er consessies gedaan mogen worden mbt de snelheid. Je komt dan snel uit op het plaatsen van business logic buiten het RDBMS want logisch gezien is de BL layer een data consumer, en niet onderdeel van de data producer, wat dus de layer is pal op de tables/views.

Mjah, als je stored procedures maakt voor DAL functionaliteit, en andere SP's maakt die de BL gaan verzorgen en die de DAL SP's gaan oproepen, heb je eigenlijk ook een logische scheiding.

Over de mogelijkheid om SP's te schrijven in C# code: ik heb hier ook al eens iets over gelezen. Ik vraag me dan wel af of die C#-taal voor SP's geen 'lite' versie zal zijn van C# zoals we die nu kennen.

[Tomatoman]

Strikt genomen hoort de business logic alleen thuis in een middle tier. In de praktijk werkt dit toch wat anders. Vaak zijn enterprise applicaties zo ingewikkeld dat de business logic nauw is verweven met de gebruikte database. Je kunt de database daarbij niet eenvoudigweg vervangen (Oracle vervangen door DB2 of zo). De business logic is dan vaak verdeeld over de business logic layer en de data access layer. Als je de database daarbij logisch verdeeld ziet als het DBMS en de data zelf, zou je het DBMS kunnen zien als een tweede business logic layer die samen met de 'echte' business logic layer zijn werk doet. Data-integriteit wordt meestal afgedwongen op database-niveau. Maar dient de business logic daar ook niet toe? Kortom, ik zie er niet zoveel theoretisch heil in om business logic en database volledig te scheiden. Praktisch is het natuurlijk wel, voornamelijk wegens onderhoudbaarheid.

Je kunt de vraag ook omdraaien (waardoor hij wel een beetje retorisch wordt). Waarom zouden er triggers, stored procedures enzovoort in een database kunnen worden ingebouwd?

[ Voor 16% gewijzigd door Tomatoman op 12-07-2003 16:27 ]

[Anoniem: 78067]

Een ander aspect dat volgens mij nog niet behandeld is is dat zaken als Triggers en in mindere maten ook SProcs en zelfs Views een veel beter garantie geven dat een stuk(je) Business Logic ook daadwerkelijk toegepast wordt dan een echte programmatische laag bovenop de database.

Theoretisch is het idd mooi dat alle functionaliteit die nodig is voor het runnen van een bedrijf in een mooie bedrijfseigen API beschikbaar is, maar in de praktijk moet de Sales afdeling gisteren een simpel niet standaard rapportje hebben of willen ze een niet standaard stukje informatie 'inpassen' in de bestaande DB structuur, want met een beetje 'gemasseer' valt dat wel in de structuur in te passen en daar bouwen ze dan zelf wel een applicatietje voor.

Moraal van het verhaal: Door zaken als SProcs, Views en Triggers kun je de daadwerkelijke business data heel goed 'beschermen' tegen 'aanvallen van ad-hoc automatisering' die theoretisch heel slecht zijn maar in de praktijk onvoorkomelijk, onmisbaar en vaak toch ook ontzettend waardevol voor een bedrijf kan zijn.

Een BLL is vanuit systeemarchitectuur oogpunt bezien ideaal maar is vaak te eenvoudig te passeren, terwijl databescherming vaak wel echt essentieel is. Het argument dat de database dan maar beter afgegrendeld moet worden vind ik niet reeel.

Wat wel waar is in mijn ogen is dat webservices (SOAP) een van de belangrijkste redenenen van het passeren van een BLL (niet geschreven op een platform dat met 'ad-hoc tools' makkelijk te benaderen is, bijv. Perl <-> VB BLL of ASP <-> Java BLL) minder noodzakelijk maakt, maar gezien de relatieve nieuwheid van dat concept is het helaas ook nog vaak slechts theoretisch.

Oh, en tegen Alarmnummer's ongenuanceerde opmerking dat:

Business Logic hoort zeker niet in de db thuis, mensen die dat zeggen zijn prutsers 1e klas

wil ik slechts zeggen dat gezien de argumenten in deze thread (zeker niet alleen van mij) het wellicht slim is eens in de spiegel te kijken voordat je begint over prutsers.

(zoals jullie wellicht weten heb ik een grote hekel aan zulke ongenuanceerde opmerkingen)

[EfBe]

Anoniem: 78067 schreef op 12 juli 2003 @ 17:47:
Moraal van het verhaal: Door zaken als SProcs, Views en Triggers kun je de daadwerkelijke business data heel goed 'beschermen' tegen 'aanvallen van ad-hoc automatisering' die theoretisch heel slecht zijn maar in de praktijk onvoorkomelijk, onmisbaar en vaak toch ook ontzettend waardevol voor een bedrijf kan zijn.

Dat heeft op zich niets met BL in sp's te maken, want een API die de functionaliteit regelt die jij middels sp's en triggers wilt beschermen kan net zo goed voor bescherming dienen. Je kunt dan middels rechten ervoor zorgen dat men de API gebruikt en niet de directe logica in de DB, omdat men botweg geen toegang heeft tot de DB.

(het webservices idee dus )

EDIT: het hoeft niet eens via rechten, maar gewoon middels het feit dat er alleen documentatie beschikbaar is voor derden van de API en niet van de SP's. Men gaat dan echt niet de moeilijke weg kiezen, maar men kiest dan de API. (en verder zijn organisaties die ad-hoc automatisering toestaan sowieso fout bezig. Wie zegt dat dergelijke heikneuters wel een goede bl layer in de database hebben gebouwd?)

[ Voor 25% gewijzigd door EfBe op 12-07-2003 18:27 ]

[Anoniem: 78067]

EfBe schreef op 12 juli 2003 @ 18:23:

Dat heeft op zich niets met BL in sp's te maken, want een API die de functionaliteit regelt die jij middels sp's en triggers wilt beschermen kan net zo goed voor bescherming dienen. Je kunt dan middels rechten ervoor zorgen dat men de API gebruikt en niet de directe logica in de DB, omdat men botweg geen toegang heeft tot de DB.

Net zo goed ja, maar niet net zo effectief. Immers, een BLL is veel makkelijker te omzeilen dan business rules die vastgelegd zijn in een DB en een API method is veel minder 'cross platform' te bereiken dan een SProc.

Men gaat dan echt niet de moeilijke weg kiezen, maar men kiest dan de API.

Het gaat niet alleen om het geval dat er al een oplossing in de bestaande API zit, hoewel dan bijvoorbeeld het feit dat de API is opgezet op een ander platform het moeilijker (niet onmogelijk) maakt om de API te gebruiken (zie mijn eerder voorbeelden). Het gaat vooral om het geval dat er nieuwe dingen bijgebouwd moeten worden.

zijn organisaties die ad-hoc automatisering toestaan sowieso fout bezig. Wie zegt dat dergelijke heikneuters wel een goede bl layer in de database hebben gebouwd?

Ieder organisatie van enige omvang staat ad-hoc automatisering toe. Ik hoop dat webservices en paradigmas als SOA (Service Oriented Architecture dan he, niet dat andere) daarin een beetje verandering kunnen brengen maar helemaal uitroeien zul je het nooit.

Daarom zeg ik dat als een business rule ECHT belangrijk is, ik hem liever in de DB vastleg dan in een API, omdat ik dan meer zekerheid heb dat hij ook daadwerkelijk gebruikt wordt dan als deze is vastgelegd in een BLL.

[EfBe]

haal je nu niet database consistency en BL door elkaar?

[Anoniem: 78067]

EfBe schreef op 12 juli 2003 @ 23:44:

haal je nu niet database consistency en BL door elkaar?

Ik vind niet dat ik de twee concepten door elkaar haal, ik combineer ze wel. Een van de taken van een BLL is ervoor te zorgen dat de data in de onderliggende data store(s) consistent is en blijft. Mijn stelling is dat data(base) consistency beter te garanderen is door het gebruik van bepaalde DB technieken dan door het gebruik van een BLL.

Stel ik heb een tabel met orders en een tabel met artikelen inclusief de daarbij behorende voorraad. Stel dat ik de logica voor het verminderen van de voorraad bij het plaatsen van iedere order in de BLL stop. Als er nu applicaties geschreven worden die om wat voor reden dan ook de BLL passeren dan klopt mijn voorraad niet meer. Als ik het via een trigger doe is mijn voorraad nog wel correct.

Overigens wil ik het gebruik van een BLL helemaal niet afraden, ik wil slechts het lijstje met voordelen van DB-native business code compleet maken, zodat een correcte afweging van de voors- en tegens mogelijk is. Perf was al genoemd, gemak ook, alleen deze ontbrak in mijn ogen nog.

[EfBe]

Ik ben het met je eens dat dataconsistency technieken in de DB thuishoren, althans, je kunt ze daar gemakkelijker implementeren. Bv triggers en ook leuke dingen als cascading deletes (en knoeiers hebben ook nog cascading updates nodig). Zou je die buiten de db implementeren dan heb je veel meer overhead nodig.

Echter, ik denk dat het wellicht nuttig is om een onderscheid te maken tussen semantisch correct en model-technisch correct. Het 1e wordt door de BL gedaan, het 2e door triggers en andere lowlevel grappen. Ik denk dat je het 1e prima buiten de DB kunt implementeren als het 2e maar gewaarborgd is.