[Alg] Business Logica in DB of in aparte laag ?

[Gabberhead]

RobIII schreef op dinsdag 14 oktober 2008 @ 11:05:
[...]

Dat zijn, IMHO, dingen die je niet door je DBMS wil laten uitvoeren maar door je applicatie. Dat een DBMS het kan wil niet zeggen dat je het ook moet doen Business Logic hoort niet in je DB maar in je applicatie.

Auw!

Je moet juist zoveel mogelijk logica door je database laten uitvoeren. Je presentatielaag wil je zo dun mogelijk houden, omdat dat voor je gebruikers het meest belastend is.
Laat je database lekker uitvoeren waar ie goed in is, en dat zijn vooral transacties en validaties op data.

Lees voor de grap eens wat artikelen over "de dikke database" door Toon Koppelaars. Dat is een Oracle man in hart en nieren, maar z'n principes zijn bruikbaar in vrijwel elke (R)DBMS.

[Woy]

RobIII schreef op dinsdag 14 oktober 2008 @ 15:56:
[...]
AFAIK bestaat er niet eens een juiste vertaling, omdat ze het niet kennen Middlename is niet zo'n heel slechte vertaling hoewel die vaak ook verwijst naar Rob <de knapste kop van de wereld> Janssen.

Ja ik weet dat ze het niet kennen, maar vaak kan je nog wel een treffende vertaling van het begrip maken. MiddleName is dat in princiepe ook wel, behalve dan dat het eigenlijk weer een andere betekenis heeft. Ik heb er ook wel vrede mee want het is best duidelijk, echter blijven dat soort dingen soms in je hoofd spoken.

NetForce1 schreef op dinsdag 14 oktober 2008 @ 16:56:
[...]

offtopic:
gewoon tussenvoegsel noemen? Wikipedia: Tussenvoegsel

Ja dat staat natuurlijk niet echt netjes tussen al je andere engelse veldnamen

Gabberhead schreef op dinsdag 14 oktober 2008 @ 17:02:
[...]


Auw!

Je moet juist zoveel mogelijk logica door je database laten uitvoeren. Je presentatielaag wil je zo dun mogelijk houden, omdat dat voor je gebruikers het meest belastend is.
Laat je database lekker uitvoeren waar ie goed in is, en dat zijn vooral transacties en validaties op data.

Lees voor de grap eens wat artikelen over "de dikke database" door Toon Koppelaars. Dat is een Oracle man in hart en nieren, maar z'n principes zijn bruikbaar in vrijwel elke (R)DBMS.

Je moet het ook niet in je presentatielaag stoppen, maar in je business laag.
Dingen als het valideren van een postcode is helemaal niet waar een database goed in is. Een database is goed in het opslaan en snel terug zoeken van relationele data.

[ Voor 29% gewijzigd door Woy op 14-10-2008 17:10 ]

[Gabberhead]

rwb schreef op dinsdag 14 oktober 2008 @ 17:07:

[...]

Je moet het ook niet in je presentatielaag stoppen, maar in je business laag.
Dingen als het valideren van een postcode is helemaal niet waar een database goed in is. Een database is goed in het opslaan en snel terug zoeken van relationele data.

Business-laag is een marketingterm bedacht voor mensen met een overdreven neiging tot het scheiden van functies en voor mensen die werken met een database die niet meer is dan een bittenbak.
Als je werkt met een 'echt' RDBMS, dan is die juist geschikt voor het valideren van data (zoals postcodes).
Maar goed, dat is een fundamentele architectuurdiscussie die we hier niet hoeven te voeren

[RobIII]

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
Business-laag is een marketingterm bedacht voor mensen...

Jij je zin; noem het de Domain layer of Model layer of zelfs vewerven Application Layer...

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
...met een overdreven neiging tot het scheiden van functies en voor mensen die werken met een database die niet meer is dan een bittenbak.

Een database is niet meer dan een bittenbak; maak er niet meer van dan het is. Een DBMS moet vooral goed zijn in het opslaan, ophalen, sorteren, combineren etc. van gegevens (sets). Dat er dan nog tegenwoordig allerlei andere foefjes in zitten kan heel leuk zijn, zolang het als doelt dient die setbewerkingen beter te maken; niet postcode validaties uit te voeren of te controleren of een kenteken wel bij de RDW bekend is; omdat het mogelijk is wil dat nog niet zeggen dat je het moet doen.

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
Als je werkt met een 'echt' RDBMS, dan is die juist geschikt voor het valideren van data (zoals postcodes).

Dikke bull. Je krijgt totale clutter van functionaliteit die her-en-der verstopt is. Dat het kan wil niet zeggen dat je het moet doen. Daarbij moet ik na het invoeren van een postcode op jouw methode eerst een roundtrip maken naar de DB om de validatie uit te voeren. Een (R)DBMS moet enkel consistentie van mijn gegevens waarborgen en validaties uitvoeren op set niveau (is een ID wel uniek, bestaat de FK, dat soort zaken) en verder niets. Er zit tegenwoordig ontzettend veel leuke functionaliteit in een beetje DB en een UDF of SP of UDT kan daarbij zeker handig zijn maar ik trek mijn wenkbrauwen telkens op als mensen complete applicaties in hun DBMS gaan zitten stouwen; de onderhoudbaarheid keldert dan hard naar het nulpunt.

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
Maar goed, dat is een fundamentele architectuurdiscussie die we hier niet hoeven te voeren

Eensch; open gerust een topic

Een kijkje in je profiel verklaarde voor mij overigens wel je standpunt/perspectief Ik zal best biased zijn, maar je maakt mij niet wijs dat jij dat niet bent

[ Voor 39% gewijzigd door RobIII op 14-10-2008 20:58 ]

[Confusion]

Gabberhead schreef op dinsdag 14 oktober 2008 @ 17:02:
Je moet juist zoveel mogelijk logica door je database laten uitvoeren. Je presentatielaag wil je zo dun mogelijk houden,

Het is niet òf de database, òf de presentatielaag. Daar zitten meestal nog wat lagen tussen tussen en als dat niet zo is, dan is er ook geen sprake van noemenswaardig business logica.

Laat je database lekker uitvoeren waar ie goed in is, en dat zijn vooral transacties en validaties op data.

Hoe kom je er bij dat een database goed is in het valideren van data? PL/SQL is een hamer.

En hoe kom je er bij op je database te vertrouwen voor de transactionele integriteit van je operaties? Ben je nooit afhankelijk van meerdere systemen dan een enkele database ofzo?

edit:
Geen zin

[ Voor 54% gewijzigd door Confusion op 14-10-2008 21:21 ]

[iH8]

Confusion schreef op dinsdag 14 oktober 2008 @ 20:59:

En hoe kom je er bij op je database te vertrouwen voor de transactionele integriteit van je operaties?

Ik dacht dat dat juist gebruikelijk was bij bijvoorbeeld het inserten van een order en het tegelijkertijd bijstellen van de voorraad? Dan ontkom je toch niet aan bv. stored procedures? Of werkt zoiets ook feilloos met transactions oid? Niet dat ik zoiets ooit geimplementeerd heb maar heb hier en daar wat meegelezen

edit!

[ Voor 0% gewijzigd door iH8 op 14-10-2008 21:25 . Reden: splits maar af dan ;) ]

[NMe]

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
[...]


Business-laag is een marketingterm bedacht voor mensen met een overdreven neiging tot het scheiden van functies en voor mensen die werken met een database die niet meer is dan een bittenbak.

Sorry, hier ben ik opgehouden met lezen omdat ik te hard moest lachen.

Als jij dat soort onzin wil geloven moet je dat zelf weten, maar ga dat niet verkondigen op een forum waar mensen rondlopen die wél weten wat ze doen, want je zet jezelf mateloos voor gek.

[Anoniem: 178962]

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
[...]


Business-laag is een marketingterm bedacht voor mensen met een overdreven neiging tot het scheiden van functies en voor mensen die werken met een database die niet meer is dan een bittenbak.
Als je werkt met een 'echt' RDBMS, dan is die juist geschikt voor het valideren van data (zoals postcodes).
Maar goed, dat is een fundamentele architectuurdiscussie die we hier niet hoeven te voeren

Microsoft Access FTW?

[BCC]

Anoniem: 178962 schreef op woensdag 15 oktober 2008 @ 02:04:
[...]

Microsoft Access FTW?

Ik schrijf mijn programma's altijd 100% in SQL De gebruiker kan best wel wat stored procedures aanroepen vanaf de commandline

[Confusion]

iH8 schreef op dinsdag 14 oktober 2008 @ 21:24:
Ik dacht dat dat juist gebruikelijk was bij bijvoorbeeld het inserten van een order en het tegelijkertijd bijstellen van de voorraad? [..] Of werkt zoiets ook feilloos met transactions oid? Niet dat ik zoiets ooit geimplementeerd heb maar heb hier en daar wat meegelezen

Natuurlijk moet je database ook transactioneel zijn, maar vaak heb je met meer state dan alleen een database te maken en moet je bij een transactie rekening houden met meer dan alleen de integriteit van de data in die database. Zeggen dat je een database moet gebruiken voor transacties, omdat 'hij daar goed in is', slaat in zo'n context nergens op, omdat het suggereert dat alle transactionele behoeften door de database vervuld kunnen worden, wat dan duidelijk niet zo is.

Als je een complete applicatie stack op je database hebt gezet en dan zegt dat 'de database' alles kan, dan doe je aan termvervuiling. Oracle levert in dat geval geen database: het levert een complete applicatie-suite.

Dan ontkom je toch niet aan bv. stored procedures?

Stored procedures en transacties zijn in principe onafhankelijk van elkaar: je kan een stored procedure gebruiken om een aantal database actie gezamelijk transactioneel te laten verlopen, maar dat hoeft niet. In het geval van je voorbeeld is er meestal sprake van twee verschillende processen die tegelijk dezelfde data lezen/manipuleren. Dan heb je ook transactiefaciliteiten nodig, zonder dat je met stored procedures werkt.

[Creepy]

BCC schreef op woensdag 15 oktober 2008 @ 07:34:
[...]

Ik schrijf mijn programma's altijd 100% in SQL De gebruiker kan best wel wat stored procedures aanroepen vanaf de commandline

Als je werkt met een 'echt' RDBMS

Ah, zie ik daar een Oracle DBA (yes, ik laat mijn vooroordelen even flink spreken hier )? Er zijn nu eenmaal klanten die niet Oracle kunnen installeren en bijv. met SQL server moeten werken, ik zou niet de persoon willen zijn die alle zaken uit je "dikke database" zou moeten porten, of erger, de klant moeten vertellen dat je applicatie alleen maar draait op Oracle..... daarom zijn juist meerdere lagen uitgevonden, zodat je bijv. makkelijk op meerdere databases kan draaien. Dat is voor jou misschien marketing geblaat, voor mij en een hoop andere is het enorm handig. Scheelt je klant weer een extra RDMBS aanschaffen en laten onderhouden. En je laat zien fatsoenlijk te kunnen ontwikkelen

[ Voor 59% gewijzigd door Creepy op 15-10-2008 09:06 ]

[Gabberhead]

Goed, aangezien er inmiddels zoveel moderators (en zelfs admins) in dit topic off-topic hebben gereageerd, mag ik aannemen dat het inmiddels wel on-topic is om architectuurzaken te bespreken.

Ik schuif even een aantal reacties bij elkaar, omdat het anders zo'n gigantisch verhaal wordt.
Natuurlijk was mijn opmerking over de business laag een beetje om te stangen. Een business layer moet je uiteraard wel modelleren, anders raak je de weg kwijt, maar eenmaal in de praktijk moet je die functionaliteit op de plek stoppen waar het hoort. Zo dicht mogelijk op de data.
Een formaatdomeintje (bv: zijn alle tekens in dit veld wel numbers, is deze datum wel in dd-mm-yyyy), die kun je wel kwijt in je presentatielaag. Maar zodra er berekingen aan te pas komen of integrity constraints (bv: er mag maar 1 manager zijn per afdeling, bepaal het jaarsalaris op basis van het maandsalaris) dan moet je dat niet aan de voorkant willen bouwen. Dat vindt je applicatieserver echt niet leuk.

@RobIII: er is een verschil tussen biased zijn en ervaring hebben. Geloof me; ik weet heus wel waar de Oracle database goed en slecht in is. Als ik jouw profiel en website een beetje bekijk, krijg ik het idee dat jij een pure voorkant ontwikkelaar bent. Ik doe beide, zowel de voorkant als in de database. Op die manier heb ik met veel technologiën kunnen werken en weet ik wel een beetje waar ik het over heb.

Je noemt het nadeel van functionaliteit in de database stoppen, de noodzaak voor roundtrips. Maar dat doet helemaal niet ter zake. Als je database een validatie in 0.01 seconde uitvoert en daar hoort een roundtrip van 0.1 bij, en daar tegenover staat dezelfde validatie in java/php/enz. van 0.5 seconde, dan weet ik het wel.

Verder ben ik het wel eens met de strekking van je verhaal: je moet elk onderdeel de zaken laten uitvoeren waar het goed in is. Het probleem is alleen dat je (en met jou menig ander in dit topic) geen beeld hebt hebt van waar een RDBMS als Oracle goed in is. Je bittenbak opmerking zegt wel genoeg wat dat betreft.

Deze is ook voor Confusion: de grootste kracht van alles in je database valideren is juist dat je alles op 1 plek hebt. Niks cluttering van functionaliteit, dus onderhoudbaarheid gaat met sprongen vooruit. Transactionele integriteit is juist extra gewaarborgd. Afhankelijkheid van meerdere systemen is al helemaal geen issue, want al die systemen spreken dezelfde functionaliteit in de database aan.

@Creepy: het zal je misschien verbazen, maar er is bijna geen enkele klant die z'n Oracle database de deur uit doet om er een andere database voor in de plaats te zetten. Dat is namelijk best duur...
In 99,9% van de gevallen is het de presentatielaag die wordt vervangen, aangezien die een veel kortere levensduur hebben en ook minder kost om te bouwen. De levenscyclus van een applicatie die ik tegenkom is meestal: client/server Forms -> WebForms/J2EE -> ADF/Apex -> volgende technologie. Maar de database blijft altijd hetzelfde.
Als je werkt op de manier die ik beschrijf boeit het helemaal niet wat het sexy smoeltje van de dag is. J2EE? Apex? Ruby? Asp.Net? Hell, zelfs de command-line programmatuur (lekker user-friendly ) van BCC is gegarandeerd integer en performed optimaal.
Stel je voor dat je al die validaties elke keer overnieuw moet schrijven. Daar wordt je klant echt niet vrolijk van.
Hoeveel klanten ken jij die meer dan 1 verschillende database leverancier hebben?

Ohja, voor ik het vergeet: nee, ik ben geen DBA... Je kunt meer met een Oracle database doen dan beheren

En als laatste @NMe: "We mock what we don't understand". Jammer dat juist een Admin zo inhoudsloos reageert. Heb je ook argumenten die je flame ondersteunen?

[Confusion]

Gabberhead schreef op dinsdag 04 november 2008 @ 09:06:
Deze is ook voor Confusion: de grootste kracht van alles in je database valideren is juist dat je alles op 1 plek hebt. Niks cluttering van functionaliteit,

Een database call is veel te duur om te valideren of pakweg een datum wel geldig is. Een hop naar de DB server en terug duurt te lang als ik en user wil informeren dat de ingevoerde datum niet klopt.

Wat betreft complexere validatie van business rules: daarvoor is de database alleen de aangewezen plaats als het gaat om validatie tegen gegevens in de database en dan nog onder bepaalde voorwaarden. Voor het grootste deel van de business rules waar ik mee te maken heb is het niet zinnig om het in een stored procedure te implementeren, omdat ik dan data van externe systemen naar de database moet gaan gooien, terwijl die data daar niets te zoeken heeft.

Afhankelijkheid van meerdere systemen is al helemaal geen issue, want al die systemen spreken dezelfde functionaliteit in de database aan.

Legacy systemen en externe systemen spreken de database niet aan, die spreken mijn applicatie aan.

[Gabberhead]

Confusion schreef op dinsdag 04 november 2008 @ 09:28:
[...]

Een database call is veel te duur om te valideren of pakweg een datum wel geldig is. Een hop naar de DB server en terug duurt te lang als ik en user wil informeren dat de ingevoerde datum niet klopt.

Wat betreft complexere validatie van business rules: daarvoor is de database alleen de aangewezen plaats als het gaat om validatie tegen gegevens in de database en dan nog onder bepaalde voorwaarden. Voor het grootste deel van de business rules waar ik mee te maken heb is het niet zinnig om het in een stored procedure te implementeren, omdat ik dan data van externe systemen naar de database moet gaan gooien, terwijl die data daar niets te zoeken heeft.

Zoals ik al in m'n vorige post zei; een formaatcontrole is prima in de applicatie.

Validatie tegen gegevens in de database moet je -altijd- in de database doen. Het uitlezen van die gegevens en vervolgens valideren in je applicatie is altijd duurder dan een call naar de database.
Als je gaat vergelijken met externe systemen, hoef je die data toch helemaal niet over te gooien? DB-linkjes, webservices, enz...

[...]
Legacy systemen en externe systemen spreken de database niet aan, die spreken mijn applicatie aan.

En jouw applicatie spreekt vervolgens de database weer aan...
Stel je voor dat jouw applicatie niet meer voldoet en er wordt een nieuwe applicatie gebouwd. Of nog gekker; de klant vraagt of de legacy- en externe systemen rechtstreeks met de database kunnen praten. In beide gevallen moet je dus alle validatiefunctionaliteit gaan herbouwen en in het laatste geval zelfs je legacy systemen en externe systemen gaan aanpassen.
En dat is een veel realistischer scenario dan dat er een andere database moet worden ingeschoven.

[Janoz]

Gabberhead schreef op dinsdag 04 november 2008 @ 10:21:

Als je gaat vergelijken met externe systemen, hoef je die data toch helemaal niet over te gooien? DB-linkjes, webservices, enz...

Die mag je me uitleggen. Externe bronnen wil ik nooit een 'db-linkje' sturen, en als je je database ook al webservice calls gaat laten doen omdat het in jouw ogen te verkiezen is boven de bussiness logic laag vraag ik me af of je uberhaupt wel een kloppend beeld hebt over wat de midden laag uberhaupt inhoud. Sowieso heb je het telkens over 'voorkant' en 'database'. Dat is alvast niet correct. Je hebt 'voorkant', 'database' en midden laag. Dat jij veel van die middenlaag in de DB op wil lossen is een keuze, maar data hoeft lang niet altijd de juiste te zijn!

En jouw applicatie spreekt vervolgens de database weer aan...

Onderandere. Wat ik de laatste tijd juist vooral zie is dat applicaties worden ingericht op de service die ze leveren en daarbij hun data uit meerdere bronnen halen. De tijd dat er enkel grote monolitische data storages zijn waarop 1 groot mainframe pakket draait waarin alles geimplementeerd is begint langzaam aan al wat verleden tijd te worden omdat de meeste mensen beseffen dat dit een achterhaalde architectuur is.

Stel je voor dat jouw applicatie niet meer voldoet en er wordt een nieuwe applicatie gebouwd. Of nog gekker; de klant vraagt of de legacy- en externe systemen rechtstreeks met de database kunnen praten. In beide gevallen moet je dus alle validatiefunctionaliteit gaan herbouwen en in het laatste geval zelfs je legacy systemen en externe systemen gaan aanpassen.
En dat is een veel realistischer scenario dan dat er een andere database moet worden ingeschoven.

Juist met een goed opgezette middenlaag is het helemaal niet nodig dat externe applicaties rechtstreeks op je database verbinden. Op die middenlaag is namelijk heel simpel een adapter te ontwikkelen waardoor de toegang goed geregeld kan worden (ook qua security). Dat is de basis van SOA.

[ Voor 11% gewijzigd door Janoz op 04-11-2008 11:09 ]

[Gabberhead]

Ah, kijk. Als je graat praten over SOA, dan hebben we ineens een heel ander verhaal. De discussie die we hier hebben gaat nog over de 'ouderwetse' (bij gebrek aan een beter woord) architectuur. Dus applicatielaag, businesslaag en datalaag. Vrij recht-toe-recht-aan.
Op het moment dat je met SOA aan de gang gaat, ben je al bezig in een heel ander soort omgeving. Helaas is nog niet iedere organisatie geschikt voor een dergelijke architectuur, of er zelfs bang voor.

Maar ook als je gebruikt maakt van een SO-architectuur, geldt het principe van de dikke database.
Stel je voor dat je een implementatie maakt met een uitgebreide validatie. (bv. controleer of de ingevoerde postcode het juiste formaat heeft bij een landcode). Die postcode formaten zijn normaal gesproken opgeslagen in een tabelletje met de landcodes. Die check leg je dus ook vast in een stored procedure.
Als je in je SOA omgeving de controles afvangt met een webservice, hoeft het aanroepende proces alleen maar die webservice aan te roepen met 2 gegevens en hij krijgt een TRUE of FALSE terug die hij aan de gebruiker kan communiceren. En dan maakt het niet uit of er 1 of 100 aanroepende processen zijn, de uitkomst is altijd gelijk.

Een duidelijk artikel over hoe je zoiets op een database-centric manier aanpakt kun je hier vinden.

Nog een verhaal over business rules van dezelfde auteur.

[Confusion]

Gabberhead schreef op dinsdag 04 november 2008 @ 10:21:
Als je gaat vergelijken met externe systemen, hoef je die data toch helemaal niet over te gooien? DB-linkjes, webservices, enz...

Daar komt die termvervuiling waar ik het eerder over had weer: een database kan geen webservice calls doen. Een "database" die wel webservice calls kan doen is een database + development stack die bij de database gebundeld zit. Maar ik heb al een development stack.

Stel je voor dat jouw applicatie niet meer voldoet en er wordt een nieuwe applicatie gebouwd. Of nog gekker; de klant vraagt of de legacy- en externe systemen rechtstreeks met de database kunnen praten.

Dat is al de vraag die de klant stelt. Maar 'rechtstreeks' is een technische oplossing en bij klanten die met een technische oplossing komen is de vraag: wat wil je echt? Er is geen klant die het een zier uitmaakt hoe we de data bij elkaar brengen, als we het maar doen.

En dat is een veel realistischer scenario dan dat er een andere database moet worden ingeschoven.

Dat dit soort applicaties 'niet meer voldoen' is net zo onwaarschijnlijk. De functie van die applicatie is juist de data op elkaar aan te laten sluiten en zowel legacy als nieuwe systemen van alle data gebruik te kunnen laten maken. De applicatie is in feite een service. Dat kan met jouw development stack net zo goed als met de mijne. Dat de jouwe het stempeltje van de DB leverancier heeft maakt weinig uit. Dat de jouwe zogenaamd 'rechtstreekser' met de database praat is marketing speak. Toegang tot de 'echte' database is voor beide development stacks even goed mogelijk en gebruikmaking van de faciliteiten die je voor high performance nodig hebt ook.

En even nog verder offtopic, over:

Helaas is nog niet iedere organisatie geschikt voor een dergelijke architectuur

En hopelijk realiseren de meeste organisaties zich dat ze er ook nooit geschikt voor zullen zijn als ze zich bij hun business houden. De hype van SOA als organisatie-architectuur slaat werkelijk helemaal nergens op. De hype van SOA als software architectuur trouwens ook niet. De helft van de GoF Design Patterns gaat over het 'service oriented' maken van je software. Wat is een factory anders dan een 'object creation service'. Wat is een facade anders dan een 'integrating service'? Natuurlijk, het niveau waarop is anders, maar de concepten zijn precies hetzelfde.

SOA is een middel, geen doel. Dat klinkt logisch en iedereen zal het beamen als ik het zo zeg, maar ondertussen zeggen mensen dingen zoals jij en het bovenstaande citaat: daarin is SOA een doel, waar organisaties 'helaas' 'nog' niet geschikt voor zijn. De vraag welk probleem de organisatie op probeert te lossen wordt niet meer gesteld en de organisatie wordt maar lukraak omgevormd, zonder dat wordt bekeken of SOA wel het goede middel is. Ook SOA is geen zilveren kogel.

[ Voor 29% gewijzigd door Confusion op 04-11-2008 14:37 ]

[NMe]

Gabberhead schreef op dinsdag 04 november 2008 @ 09:06:
En als laatste @NMe: "We mock what we don't understand". Jammer dat juist een Admin zo inhoudsloos reageert. Heb je ook argumenten die je flame ondersteunen?

Als jij iets zegt als "Business-laag is een marketingterm bedacht voor mensen met een overdreven neiging tot het scheiden van functies en voor mensen die werken met een database die niet meer is dan een bittenbak." dan kan ik niet anders zeggen dan dit: de pot verwijt de ketel. Je steekt hier zelf de draak met iets wat je duidelijk niet begrijpt, want anders zou je die uitspraak nooit gemaakt hebben. Als jij de voordelen van een businesslaag niet ziet ondanks de argumenten daarvoor die hier gepost zijn (en verder prima te vinden zijn op het internet) dan heb je een belangrijk onderdeel van software engineering gewoon niet begrepen. Dat is niet erg, maar je loopt intussen wel de gekste dingen te verkondigen als waarheid.

Gabberhead schreef op dinsdag 14 oktober 2008 @ 19:10:
Als je werkt met een 'echt' RDBMS, dan is die juist geschikt voor het valideren van data (zoals postcodes).

We weten allemaal dat Oracle vrij krachtig is dankzij de uitgebreide validatiemogelijkheden die het biedt en PL/SQL, en áls je database dit kan zonder veel overhead is er weinig reden om niet te valideren bij inserts en updates. Echter, als je alle validatie alleen daar stopt ben je gewoon fout bezig.

Het feit dat mensen MVC implementeren is echt niet iets dat over één dag ijs is gegaan. Er zijn meer mensen die verkondigen dat dat handig/beter/sneller is om de redenen die je zelf ook wel na kan gaan lezen op Wikipedia, die ga ik hier niet herhalen. Toon Koppelaars en zijn "Dikke Database" lijkt echter redelijk uniek te zijn in zijn standpunt.

[djc]

Gabberhead schreef op dinsdag 04 november 2008 @ 10:21:
En jouw applicatie spreekt vervolgens de database weer aan...
Stel je voor dat jouw applicatie niet meer voldoet en er wordt een nieuwe applicatie gebouwd. Of nog gekker; de klant vraagt of de legacy- en externe systemen rechtstreeks met de database kunnen praten. In beide gevallen moet je dus alle validatiefunctionaliteit gaan herbouwen en in het laatste geval zelfs je legacy systemen en externe systemen gaan aanpassen.
En dat is een veel realistischer scenario dan dat er een andere database moet worden ingeschoven.

Dat klinkt als database vendor lock-in. Ik wil helemaal niet gebonden zijn aan maar 1 mogelijke leverancier voor mijn database! SQL is niet voor niets gestandaardiseerd, als ik mijn database-shizzle alleen maar op Oracle kan uitvoeren is het allemaal wel heel beperkt. De kracht van het MVC-model is juist dat ik ook andere soorten storage voor mijn modellen kan gebruiken (object-oriented databases, document-oriented databases), en dat ik in mijn applicatie dan alleen een alternatieve M-laag hoef te schrijven...

Overigens misschien niet zo gek als een van de mods dit hele onderwerp kan afsplitsen.

[ Voor 3% gewijzigd door djc op 04-11-2008 12:49 ]

[Creepy]

Gabberhead schreef op dinsdag 04 november 2008 @ 09:06:
@Creepy: het zal je misschien verbazen, maar er is bijna geen enkele klant die z'n Oracle database de deur uit doet om er een andere database voor in de plaats te zetten. Dat is namelijk best duur...
In 99,9% van de gevallen is het de presentatielaag die wordt vervangen, aangezien die een veel kortere levensduur hebben en ook minder kost om te bouwen. De levenscyclus van een applicatie die ik tegenkom is meestal: client/server Forms -> WebForms/J2EE -> ADF/Apex -> volgende technologie. Maar de database blijft altijd hetzelfde.

Over wat voor apps heb je het nu? Ik over apps die bij meerdere klanten draaien. Juist omdat ze niet snel overstappen naar een andere is het dus zaak je app op de DB van de klant te kunnen laten draaien. Door alles in Orcale specifieke zut te stoppen is je app een stuk minder snel in te zetten op een MS SQL DB. Er zijn apps genoeg die prima gebruik maken van een RRDBMS en toch op meer dan 1 RDMBS draaien.

Als je die functionaliteit toch in je DB houdt dan zul je dit voor elk RDMBS moeten dupliceren en onderhouden. Code die wel verschillend is maar toch hetzelfde doet. Dat is niet goed voor de onderhoudbaarheid van je app.

Als je werkt op de manier die ik beschrijf boeit het helemaal niet wat het sexy smoeltje van de dag is. J2EE? Apex? Ruby? Asp.Net? Hell, zelfs de command-line programmatuur (lekker user-friendly ) van BCC is gegarandeerd integer en performed optimaal.
Stel je voor dat je al die validaties elke keer overnieuw moet schrijven. Daar wordt je klant echt niet vrolijk van.

Alleen het smoeltje vervangen?
Als je dat doet terwijl je de klant een echte upgrade belooft is dat echt enorm jammer....... van een grote ouderwetste web app naar iets wat veel sneller reageert m.b.v. Ajax (om maar een sexy term van de dag te pakken) is veel meer dan alleen het smoeltje vervangen, je zult ook de achterkant moeten aanpassen.

Validaties? Over wat voor validaties praat je precies? Je kan prima validaties zo maken dat je toch van DB kan wisselen in je applicatie i.p.v. alles voor 1 specifiek DMBS te schrijven. Ok, dat is geen noodzaak als je voor elke klant een eigen losse applicatie schrijft maar dat wil je niet in alle gevallen

Hoeveel klanten ken jij die meer dan 1 verschillende database leverancier hebben?

Tientallen (er is meer dan Oracle en MS SQL server ).

Wedervraag: hoeveel apps kan jij die voor 1 specifieke klant en 1 specifkek RDMBS geschreven zijn? Als dat alles is wat je bedoelt (en daar lijkt het op) dan heb je het wat mij betreft veel te grote projecten (die echt zo groot niet hoeven zijn) die teveel kosten (aangezien je een hoop opnieuw bakt....), waarvan het gros mislukt en de klant vaak niet te vreden over is... jups, back in the 80ties & 90ties toen bijna 80% (tachtig ja, geen typo) van alle grote projecten mislukte.....

Ohja, voor ik het vergeet: nee, ik ben geen DBA... Je kunt meer met een Oracle database doen dan beheren

No shit, dat hoef je niet te vertellen hoor. De meesten die hier reageren kennen Oracle echt wel.

[ Voor 4% gewijzigd door Creepy op 04-11-2008 13:06 ]

[RobIII]

Gabberhead schreef op dinsdag 04 november 2008 @ 09:06:
@RobIII: er is een verschil tussen biased zijn en ervaring hebben. Geloof me; ik weet heus wel waar de Oracle database goed en slecht in is.

Ik ook; laten we het daar maar op houden

Gabberhead schreef op dinsdag 04 november 2008 @ 09:06:
Als ik jouw profiel en website een beetje bekijk, krijg ik het idee dat jij een pure voorkant ontwikkelaar bent.

Dan kijk je niet goed Ik ben geen fulltime DBA'er en heb allicht meer ervaring met MSSQL dan met Oracle, MySQL etc maar ik ken van alle DBMS'en genoeg om in elk geval gefundeerd te kunnen ranten uitspraken te doen

Maar goed; jij hebt je ei van columbus gevonden, net als wij. Meningen verschillen; zo zal het altijd wel blijven. We hoeven het ook niet eens te zijn

[ Voor 24% gewijzigd door RobIII op 04-11-2008 14:26 ]

[.oisyn]

RobIII schreef op dinsdag 04 november 2008 @ 14:22:
We hoeven het ook niet eens te zijn

Klopt, maar er is natuurlijk wel een verschil tussen een meningsverschil op basis van valide argumenten en die op basis van klinklare onzin .

Hey, waar is me knuppel nou? Oh wacht, in het hoenderhok

[Gabberhead]

.oisyn schreef op dinsdag 04 november 2008 @ 15:11:
[...]

Klopt, maar er is natuurlijk wel een verschil tussen een meningsverschil op basis van valide argumenten en die op basis van klinklare onzin .

Hey, waar is me knuppel nou? Oh wacht, in het hoenderhok

My shit smells just as bad as yours

Ach, mijn argumenten zijn net zo valide als de tegenargumenten, want we hebben ze schijnbaar allebei in de praktijk meegemaakt.
Als ik zie dat bijvoorbeeld Creepy voornamelijk out-of-the-box oplossingen maakt die bij verschillende klanten worden geïmplementeerd, terwijl ik voornamelijk klanten ondersteun in maatwerk projecten of bij in-house ontwikkeling, dan heb je al een compleet andere belevingswereld.
Hij heeft een stabiel pakket waar bij verschillende klanten een andere database wordt ingeschoven. Ik heb voornamelijk klanten met een stabiele database waar verschillende applicaties op moeten worden gebouwd.

Als ontwikkelaar ben je altijd geneigd om je architectuur zo in te richten dat herbruikbare onderdelen in een zo stabiel mogelijke omgeving terecht komen. Maar dat hoeft niet meteen de beste oplossing te zijn. In een Oracle RDBMS ben je altijd beter af met je business rules in de database, performance en data integriteit zijn daar het meest bij gebaat. Dat het vanwege de kosten of andere redenen niet altijd kan, is nog geen argument waarom het voorgaande niet waar zou zijn.

@Confusion: wie heeft het over een development stack? PL/SQL is een integraal onderdeel van de Oracle database. Daarmee heb je al direct je aanroepen naar webservices te pakken. Oude voorbeeldjes. Bovendien is het geen development tool, maar een middel. Dat mag je ontsluiten met elke tool die je zelf kiest.

Ik hoorde ook nog de term vendor-lock-in vallen.. Ook niet valide. Ja, je kunt je hele stack (inclusief hardware) bij Oracle aanschaffen, maar je kunt ook elk willekeurig onderdeel vervangen door een ander. Je -kunt- ook je hele MVC model bij verschillende vendors onderbrengen, maar het is dus niet zo dat je dat ook meteen -moet- doen... Sterker nog, ik heb weinig toepassingen gezien waar dat echt handig is.
Het blijft wel een mooi theoretisch principe. En dat is meteen de crux van dit hele topic; er zijn heel veel theoretische argumenten te bedenken voor allebei de standpunten. Theoretisch ben ik het ook helemaal eens met een groot deel van de mensen hier (het scheiden van lagen in je model, MVC, SOA, enz..), alleen ik merk in mijn dagelijkse werk dat de praktijk de theorie heeft ingehaald.

@-NMe-: je kent me niet, je doet uitspraken over mij die niet kloppen en je leest duidelijk niet wat ik post. Anders zou je gelezen hebben dat ik wel het voordeel zie van MVC en businesslagen, maar dat ik het heb over de technische implementatie ervan. For the record: Toon Koppelaars is een authoriteit met zijn opvattingen en hij staat zeker niet alleen. Hij krijgt alleen kritiek uit de hoek van de Java ontwikkelaars die hem en de kracht van de database niet kennen. Zodra ze zijn verhaal een keer gehoord hebben, zijn ze overtuigd. Dat heb ik al regelmatig meegemaakt in de praktijk.

[RobIII]

Gabberhead schreef op dinsdag 04 november 2008 @ 15:59:
For the record: Toon Koppelaars is een authoriteit met zijn opvattingen en hij staat zeker niet alleen. Hij krijgt alleen kritiek uit de hoek van de Java ontwikkelaars die hem en de kracht van de database niet kennen. Zodra ze zijn verhaal een keer gehoord hebben, zijn ze overtuigd. Dat heb ik al regelmatig meegemaakt in de praktijk.

Misschien een authoriteit in het Oracle wereldje, maar ik (en ik wed velen met mij) had er nog nooit van gehoord. Die 'authoriteit' valt wel mee denk ik. En zelfs 'authoriteiten' zeggen wel eens dingen die gewoonweg niet waar zijn of niet volledig of... En ik geloof niet dat hij alleen tegenstand van de java-hoek krijgt; van mij had 'ie ook tegenstand gehad... Ik heb iig al eens her-en-der wat van 'm doorgebladerd sinds je z'n naam liet vallen en ik ben niet impressed; sterker: ik vind 'm vol onzin. En ont-zet-tend vol van zichzelf by the way. En daar laat ik het bij; ik zie verder weinig nut in een welles/nietes discussie.

[ Voor 14% gewijzigd door RobIII op 04-11-2008 16:21 ]

[Creepy]

Als ik zie dat bijvoorbeeld Creepy voornamelijk out-of-the-box oplossingen maakt die bij verschillende klanten worden geïmplementeerd, terwijl ik voornamelijk klanten ondersteun in maatwerk projecten of bij in-house ontwikkeling, dan heb je al een compleet andere belevingswereld.

Je vergeet te melden dat blijkbaar al je klanten Oracle hebben

For the record: Toon Koppelaars is een authoriteit met zijn opvattingen en hij staat zeker niet alleen. Hij krijgt alleen kritiek uit de hoek van de Java ontwikkelaars die hem en de kracht van de database niet kennen. Zodra ze zijn verhaal een keer gehoord hebben, zijn ze overtuigd. Dat heb ik al regelmatig meegemaakt in de praktijk.

Moa, als ik papers uit 2007 lees waarbij hij stelt dat Java en eventueel J2EE te complex zijn voor het gros van de database ontwikkelaars dan snap ik waar hij vandaan komt en jij ook. Vanuit de DB en dan voornamelijk vanuit Oracle en Oracle Forms/Applications en daar apps mee bouwen. Niet vanuit het oogpunt van een software ontwikkelaar. Anders denk je niet zo lichtjes over het wisselen van een volledige software ontwikkelstraat. Zoiezo verassend dat hij, en jij ook, denken mee te moeten gaan met de taal/hype van de dag om apps te kunnen bouwen en dan ook nog is alleen de GUI hiervoor gebruiken en de rest in de DB proppen juist *omdat* je dan eenvoudig kan wisselen.... Een ander voordeel dan dat alleen heb ik jou nog niet zien noemen en zie ik ook niet snel terug in de papers en artikelen van Toon Koppelaars.

Ik ben niet per definitie tegen een dikke DB maar tijden veranderen, bedrijven fuseren, maatwerk apps moeten worden aangepast dus ook de DB zal moeten veranderen en dan is de "dikke database" wat mij betreft een nadeel i.p.v. een voordeel.

[NMe]

Gabberhead schreef op dinsdag 04 november 2008 @ 15:59:
@Confusion: wie heeft het over een development stack? PL/SQL is een integraal onderdeel van de Oracle database. Daarmee heb je al direct je aanroepen naar webservices te pakken. Oude voorbeeldjes. Bovendien is het geen development tool, maar een middel. Dat mag je ontsluiten met elke tool die je zelf kiest.

En dat is meteen de crux van dit hele topic; er zijn heel veel theoretische argumenten te bedenken voor allebei de standpunten. Theoretisch ben ik het ook helemaal eens met een groot deel van de mensen hier (het scheiden van lagen in je model, MVC, SOA, enz..), alleen ik merk in mijn dagelijkse werk dat de praktijk de theorie heeft ingehaald.

Die mensen die tegen je ageren werken voor een groot deel ook al jaren met MVC, SOA, of welk ander acroniem dan ook, en diezelfde mensen brengen nog steeds met liefde die theorie in de praktijk.

@-NMe-: je kent me niet, je doet uitspraken over mij die niet kloppen

Ik trek conclusies uit je posts. Als jij in de ene post zegt dat de business laag een verzonnen "marketingterm" en later beweert dat je er wel degelijk voordeel in ziet, dan kan ik je niet meer serieus nemen.

en je leest duidelijk niet wat ik post. Anders zou je gelezen hebben dat ik wel het voordeel zie van MVC en businesslagen, maar dat ik het heb over de technische implementatie ervan.

Dit is een zin zonder inhoud. We hebben het allemaal over de technische implementatie. Jij hebt het over een implementatie die afwijkt van MVC en zoveel mogelijk business logic in de datalaag stopt, wij zeggen dat dat een slecht idee is.

For the record: Toon Koppelaars is een authoriteit met zijn opvattingen en hij staat zeker niet alleen. Hij krijgt alleen kritiek uit de hoek van de Java ontwikkelaars die hem en de kracht van de database niet kennen. Zodra ze zijn verhaal een keer gehoord hebben, zijn ze overtuigd. Dat heb ik al regelmatig meegemaakt in de praktijk.

Ik ben geen Java-ontwikkelaar (ik "spreek" geen woord Java). Ik heb wat van zijn presentaties doorgelezen en wat sheets bekeken en ik zie eigenlijk alleen een onsamenhangende lading buzzwords, mogelijk/waarschijnlijk voornamelijk bedoeld om onwetende managers ervan te overtuigen dat zijn product een goede aanschaf is voor hun bedrijf. En ja, ik weet dat die zin zowel een aanname als een stereotype bevat, maar zo komt een deel van zijn werk in elk geval op mij over.

[Janoz]

Ik heb in verschillende maatwerk trajecten meegelopen. Eén daarvan was een zogenaamde 'dikke database'. Het grootste probleem dat we daarmee hadden was dat stored procedures en triggers maar beperkt testbaar waren en dat de tooling mbt bijvoorbeeld refactoring beperkter waren dan ik gewend was.

Uiteindelijk was het grootste probleem dat het valideren van de correctheid van de dikke database lastig was.

De projecten waarop ik gewerkt heb was correctheid belangrijker dan efficiëntie (en dat betekend niet dat efficiëntie niet belangrijk was), maar efficiëntie is over het algemeen ook op te lossen door extra hardware.

Maar goed, mijn argumentatie zal wel niet valide zijn aangezien ik een Java specialist ben. Dat de afgelopen paar projecten die ik gedaan heb juist van het kaliber waren 'Help, we hebben een uitgebreide core applicatie die in een mainframe/dikke database draait maar ondertussen durven we niks meer aan te passen omdat we geen garanties kunnen geven dat alles correct blijft werken en de persoon die het gebouwd heeft en alle kennis in zijn hoofd heeft is vorig jaar met pensioen gegaan' zal ook wel weggewimpeld worden.

[pedorus]

Gabberhead schreef op dinsdag 04 november 2008 @ 15:59:
For the record: Toon Koppelaars is een authoriteit met zijn opvattingen en hij staat zeker niet alleen. Hij krijgt alleen kritiek uit de hoek van de Java ontwikkelaars die hem en de kracht van de database niet kennen. Zodra ze zijn verhaal een keer gehoord hebben, zijn ze overtuigd. Dat heb ik al regelmatig meegemaakt in de praktijk.

Ik dacht dat Ramez Elmasri een authoriteit was, maar blijkbaar kende ik Toon Koppelaars nog niet.

[Confusion]

Gabberhead schreef op dinsdag 04 november 2008 @ 15:59:
@Confusion: wie heeft het over een development stack? PL/SQL is een integraal onderdeel van de Oracle database. Daarmee heb je al direct je aanroepen naar webservices te pakken. Oude voorbeeldjes. Bovendien is het geen development tool, maar een middel. Dat mag je ontsluiten met elke tool die je zelf kiest.

Als iets libraries heeft om webservice calls te doen, dan is het onderdeel van een development stack. Dat heeft niets met IDE's te maken, maar voornamelijk met libraries, bindings, mogelijkheden.

Webservice calls doen vanuit een stored procedure is onverstandig. Je moet allerlei code dupliceren, omdat ze zowel in je code als in PL/SQL geimplementeerd moet worden. De webservice moet twee keer aangeroepen worden om de data op beide plaatsen beschikbaar te hebben en de data moet twee keer gemasseerd worden. Iets eenvoudigs als de configuratie van de locatie van de webservice zal op twee plaatsen voor moeten komen. Tenzij je je database gaat gebruiken om die tijdelijke data uit de webservice erin te gooien, tegen je applicatie te roepen: 'het is gedaan' en die dan de data weer uit de database te laten halen. Dat is natuurlijk ook verre van overzichtelijk en elegant.

Maar je bedoelde dus echt alleen PL/SQL? Dat is toch potdorie geen vervanging voor een echte programeertaal?!

[NMe]

Confusion schreef op dinsdag 04 november 2008 @ 17:41:
[...]

Maar je bedoelde dus echt alleen PL/SQL? Dat is toch potdorie geen vervanging voor een echte programeertaal?!

Zeg dat tegen de bedrijven die nog steeds met complete Oracle Forms-applicaties werken.

[bigbeng]

offtopic:
Met enigzins lede ogen heb ik deze discussie aangezien waarbij vijf mods/admins zich tegen 1 iemand keren. Hoewel Gabberhead een sterke mening vertoont, zie ik niet in waarom zijn argumenten met zoveel kracht door de wc gespoeld worden. Ik ga mijzelf niet in de "inhoudelijke" discussie mengen, omdat ik geen zin heb om dogma's te moeten doorbreken, maar ik zou het wel op prijs stellen als mensen gefundeerde uitspraken doen, met argumenten erbij. Impliciete argumenten, zoals nu tussen de regels door uit de posts gehaald moeten worden, kunnen prima vermeden worden, zonder afbreuk te doen aan de discussie. En een linkje naar webresources waar aan wordt gerefereerd zou hier en daar ook wel op zijn plaats zijn.

Ik stel voor dat iedereen nog eens zijn posts doorleest en kijkt of het mogelijk niet te aggressief is opgesteld. Want als ik de TS was, en de replies zou lezen die hier gegeven zijn, dan zou ik maken dat ik wegkwam.

En tenslotte, gezien de afwijking van de oorspronkelijke vraag, steun ik het voorstel van djc om het topic af te splitsen.

[Gabberhead]

Confusion schreef op dinsdag 04 november 2008 @ 17:41:
[...]

Als iets libraries heeft om webservice calls te doen, dan is het onderdeel van een development stack. Dat heeft niets met IDE's te maken, maar voornamelijk met libraries, bindings, mogelijkheden.

Webservice calls doen vanuit een stored procedure is onverstandig. Je moet allerlei code dupliceren, omdat ze zowel in je code als in PL/SQL geimplementeerd moet worden. De webservice moet twee keer aangeroepen worden om de data op beide plaatsen beschikbaar te hebben en de data moet twee keer gemasseerd worden. Iets eenvoudigs als de configuratie van de locatie van de webservice zal op twee plaatsen voor moeten komen. Tenzij je je database gaat gebruiken om die tijdelijke data uit de webservice erin te gooien, tegen je applicatie te roepen: 'het is gedaan' en die dan de data weer uit de database te laten halen. Dat is natuurlijk ook verre van overzichtelijk en elegant.

Maar je bedoelde dus echt alleen PL/SQL? Dat is toch potdorie geen vervanging voor een echte programeertaal?!

Je hebt echt geen idee van de kracht van PL/SQL. Nee het is geen object geörienteerde taal, maar moet dat? Ik ken applicaties die al tientallen jaren stabiel draaien op alleen PL/SQL...
En waarom moet je in godsnaam code dupliceren bij een aanroep van een webservice vanuit een stored procedure? Het externe systeem biedt een webservice aan en de stored procedure roept deze aan. Daar is helemaal niks anders aan in welke andere omgeving dan ook.

@-NMe: wat is er nou weer mis met applicaties die compleet in Forms draaien? Je opmerking is nogal laatdunkend, terwijl er genoeg bedrijven zijn die niks anders willen, gewoon omdat het simpel te gebruiken is, goed onderhoudbaar, goed performed en stabiel draait.

@bigbeng: bedankt voor de mental support Het zou inderdaad heel prettig zijn als één van de aanwezige mods dit topic splitst.

Nog een vraag om eens te kijken waar iedereen vandaan komt. Kan iedereen eens posten met wat voor programmeerstack ze het liefst werken en waar ze welke functionaliteit leggen? Ik hoor veel geroep over layers, maar hoe ze dat technisch implementeren heb ik nog niet gehoord.

[Confusion]

Gabberhead schreef op woensdag 05 november 2008 @ 08:49:
Je hebt echt geen idee van de kracht van PL/SQL.

Ik heb echt wel een idee van de kracht van PL/SQL. Ook van de tekortkomingen.

[whoami]

Gabberhead schreef op woensdag 05 november 2008 @ 08:49:
[...]


Je hebt echt geen idee van de kracht van PL/SQL. Nee het is geen object geörienteerde taal, maar moet dat? Ik ken applicaties die al tientallen jaren stabiel draaien op alleen PL/SQL...
En waarom moet je in godsnaam code dupliceren bij een aanroep van een webservice vanuit een stored procedure? Het externe systeem biedt een webservice aan en de stored procedure roept deze aan. Daar is helemaal niks anders aan in welke andere omgeving dan ook.

Ik heb me al de hele tijd afzijdig gehouden, maar ik vraag me toch af:
- wat met testability als je al je Business Logica in stored procedures & triggers plaatst ?
- wat qua onderhoudbaarheid ? Refactoring support ? Kan je na een aantal maanden / jaren makkelijk iets wijzigen (ingrijpend) zonder dat je moet vrezen dat heel de boel in elkaar valt ?
Als je met een fat database gaat werken, zit je dan niet met het probleem dat al je logica versnipperd / verspreid zit ?
- hoe kan je je probleem domein goed modelleren als je zo te werk gaat ? (En dan heb ik het niet over je database-schema, maar over de logica die op die DB draait. Een domein is nl. meer dan enkel de data die in de DB zit).

Nog een vraag om eens te kijken waar iedereen vandaan komt. Kan iedereen eens posten met wat voor programmeerstack ze het liefst werken en waar ze welke functionaliteit leggen? Ik hoor veel geroep over layers, maar hoe ze dat technisch implementeren heb ik nog niet gehoord.

Vind ik een beetje een onzinnige vraag, aangezien ieder probleem een andere set van dev-tools kan vereisen.
Het is ook niet de bedoeling dat we hier een opsomtopic van maken.

[Gabberhead]

whoami schreef op woensdag 05 november 2008 @ 09:04:
[...]

Ik heb me al de hele tijd afzijdig gehouden, maar ik vraag me toch af:
- wat met testability als je al je Business Logica in stored procedures & triggers plaatst ?

Nog nooit problemen mee gehad. Je kunt gebruik maken van testtools als Log4PLSQL, maar ik zorg altijd voor code die goed testbaar is. Dat heb je voor een groot gedeelte zelf in de hand.
In principe kun je elke procedure of trigger apart testen met een losse aanroep en daarnaast kun je je code in debugmode compileren. Dat is ruim voldoende voor al je testwensen.

- wat qua onderhoudbaarheid ? Refactoring support ? Kan je na een aantal maanden / jaren makkelijk iets wijzigen (ingrijpend) zonder dat je moet vrezen dat heel de boel in elkaar valt ?

Als je met een fat database gaat werken, zit je dan niet met het probleem dat al je logica versnipperd / verspreid zit ?

Kwestie van goed ontwerpen, documenteren en programmeren. Hou je netjes aan standaarden zoals CDM en elke willekeurige ontwikkelaar kan makkelijk doorgronden wat je gedaan hebt.
Maar dat is uiteraard niet anders bij elke willekeurige andere programmeertaal/omgeving.
Ik zit momenteel te werken op een systeem dat in 1997 is gebouwd en waar regelmatig stukken aan zijn gebouwd. Doordat er goed volgens de standaarden is gebouwd, kan ik in één of twee oogopslagen zien wat een bepaalde wijziging van mij voor gevolgen zal hebben voor de rest.

- hoe kan je je probleem domein goed modelleren als je zo te werk gaat ? (En dan heb ik het niet over je database-schema, maar over de logica die op die DB draait. Een domein is nl. meer dan enkel de data die in de DB zit).

Dat is wat ik al een paar keer heb geprobeerd uit te leggen in dit topic. Je ontwerp in gescheiden layers hoeft niet persé te resulteren in programmatuur in duidelijk gescheiden layers.

[...]
Vind ik een beetje een onzinnige vraag, aangezien ieder probleem een andere set van dev-tools kan vereisen.
Het is ook niet de bedoeling dat we hier een opsomtopic van maken.

Ik vind het toch wel redelijk relevant. Aangezien ik een aantal keer ben aangevallen op het feit dat ik de business layer in de database stop, ben ik gewoon benieuwd hoe anderen dat oplossen. De theorie is hier wel een paar keer beschreven, maar een praktijkvoorbeeld heb ik nog niet gehoord. Ik denk namelijk dat er veel zullen zijn die ook hun model in elkaar schuiven tijdens het bouwen.

[whoami]

Gabberhead schreef op woensdag 05 november 2008 @ 09:52:
[...]

Nog nooit problemen mee gehad. Je kunt gebruik maken van testtools als Log4PLSQL, maar ik zorg altijd voor code die goed testbaar is. Dat heb je voor een groot gedeelte zelf in de hand.
In principe kun je elke procedure of trigger apart testen met een losse aanroep en daarnaast kun je je code in debugmode compileren. Dat is ruim voldoende voor al je testwensen.

Kan je ook logica gaan testen zonder dat je daarvoor afhankelijk bent van je databank ?
Als je met automatische testen bezig bent, dan wil je nl. niet dat je de gegevens in je (test)databank gaat gaan wijzigen. Die tests moeten nl. verschillende keren per dag kunnen lopen, en met dezelfde input bv.

Kwestie van goed ontwerpen, documenteren en programmeren. Hou je netjes aan standaarden zoals CDM en elke willekeurige ontwikkelaar kan makkelijk doorgronden wat je gedaan hebt.

Mja, maar dat is met andere systemen ook zo, dus geen argument voor een fat DB.

Ik vind het toch wel redelijk relevant. Aangezien ik een aantal keer ben aangevallen op het feit dat ik de business layer in de database stop, ben ik gewoon benieuwd hoe anderen dat oplossen. De theorie is hier wel een paar keer beschreven, maar een praktijkvoorbeeld heb ik nog niet gehoord. Ik denk namelijk dat er veel zullen zijn die ook hun model in elkaar schuiven tijdens het bouwen.

Nou vooruit.
Ik werk momenteel aan een applicatie die:
- een gescheiden business laag bevat. Deze laag bevat 'mijn model'. Hierin is mijn probleemdomein op een (redelijk) OO manier gemodelleerd. Deze laag bevat ook de interfaces die 'het contract' zijn van hoe ik met de databank praat.

- In principe zou ik de classes die die interfaces implementeren, in een aparte DLL moeten huisvesten, maar dat heb ik nu -voor het gemak- niet gedaan. In de DLL waarin mijn business laag zit, zit er dus ook een implementatie van mijn repositories (die gebruik maken van NHibernate) om met de DB te praten.
Nu zou je kunnen zeggen dat ik hier 2 lagen in één laag samengesmolten heb, maar daar ben ik het niet mee eens. Ik kan die implementatie nl. makkelijk naar een andere DLL verhuizen. Mijn business objecten gaan ook nooit rechtstreeks de DB gaan aanspreken, alles gaat via die repositories.
Als een business object dus zelf de DB moet aanspreken, dan doet hij dat ook via een repository interface.

- Dan heb ik mijn 'client' laag. De UI waar de gebruiker 'tegen spreekt'. Deze laag is trouwens ook verantwoordelijk voor het starten / committen van bv een transactie. Dit is zo, omdat het deze laag is die 'de context' weet waarin een bepaalde actie gebeurd.

- Ik heb dan ook uiteindelijk een DB (SQL Server). Deze DB is goed genormaliseerd, en zorgt ervoor dat de data consistent opgeslagen wordt. (Unique indexes, foreign key constraints, .... ) Verder bevat deze DB geen business logica.
(Wat ik eventueel wel nog door de DB zou laten afhandelen, is het plaatsen van data in history-tabellen net voordat er een wijziging op een bepaald record gebeurt (dmv een trigger); maar verder ga ik niet).

In principe zou je kunnen stellen dat de manier waarop ik mijn data opsla, een implementatie detail is. Mijn applicatie (zowel UI als BL) hoeven niet te weten dat alles uiteindelijk in een SQL Server DB opgeslagen wordt. Het kan evengoed een Oracle DB zijn, of zelfs een set van XML bestanden.
Dit is vooral handig voor de unit-tests die ik heb. Ik wil bv niet dat mijn tests iedere keer naar de DB gaan om een bepaalde business-regel te testen. Ik voorzie hier dan gewoon een andere implementatie van mijn IRepository - interfaces.

[Gabberhead]

whoami schreef op woensdag 05 november 2008 @ 10:40:
[...]
Kan je ook logica gaan testen zonder dat je daarvoor afhankelijk bent van je databank ?
Als je met automatische testen bezig bent, dan wil je nl. niet dat je de gegevens in je (test)databank gaat gaan wijzigen. Die tests moeten nl. verschillende keren per dag kunnen lopen, en met dezelfde input bv.

Dat is afhankelijk van de manier waarop je geprogrammeerd hebt. In sommige omgevingen is het inderdaad belangrijk om afhankelijk van de databank te testen en zul je je programmatuur anders indelen (bijvoorbeeld door DML naar aparte procedures te verplaatsen). In andere gevallen zul je je DML wel opnemen bij de logica in 1 procedure. Dan wordt het 'los' testen wel lastiger, want dan zul je voor de tests je code moeten aanpassen om bijvoorbeeld alleen messages terug te geven in plaats van de DML uit te voeren.

Aan de andere kant, waarom wil je los testen? In een goeie test neem je de hele stack mee inclusief de databank. Het kan wel zo zijn dat je logica alles doet wat je verwacht, maar dat er bij de insert op de tabel toch iets verkeerd gaat. Unit testing is ook niet heel gebruikelijk in de Oracle wereld op de manier zoals dat bijvoorbeeld in Java gebeurt. Ik test veel vaker 'alles wat er met de data gebeurt', dat is dus logica + DML.

[...]
Mja, maar dat is met andere systemen ook zo, dus geen argument voor een fat DB.

Nope, maar dus ook geen argument tegen

[...]

Nou vooruit.
Ik werk momenteel aan een applicatie die:
- een gescheiden business laag bevat. Deze laag bevat 'mijn model'. Hierin is mijn probleemdomein op een (redelijk) OO manier gemodelleerd. Deze laag bevat ook de interfaces die 'het contract' zijn van hoe ik met de databank praat.

- In principe zou ik de classes die die interfaces implementeren, in een aparte DLL moeten huisvesten, maar dat heb ik nu -voor het gemak- niet gedaan. In de DLL waarin mijn business laag zit, zit er dus ook een implementatie van mijn repositories (die gebruik maken van NHibernate) om met de DB te praten.
Nu zou je kunnen zeggen dat ik hier 2 lagen in één laag samengesmolten heb, maar daar ben ik het niet mee eens. Ik kan die implementatie nl. makkelijk naar een andere DLL verhuizen. Mijn business objecten gaan ook nooit rechtstreeks de DB gaan aanspreken, alles gaat via die repositories.
Als een business object dus zelf de DB moet aanspreken, dan doet hij dat ook via een repository interface.

- Dan heb ik mijn 'client' laag. De UI waar de gebruiker 'tegen spreekt'. Deze laag is trouwens ook verantwoordelijk voor het starten / committen van bv een transactie. Dit is zo, omdat het deze laag is die 'de context' weet waarin een bepaalde actie gebeurd.

Wat nu als er een nieuwe applicatie tegen dezelfde database gaat praten. Moet die ontwikkelaar het hele transactie mechanisme gaan herbouwen in zijn applicatie?

- Ik heb dan ook uiteindelijk een DB (SQL Server). Deze DB is goed genormaliseerd, en zorgt ervoor dat de data consistent opgeslagen wordt. (Unique indexes, foreign key constraints, .... ) Verder bevat deze DB geen business logica.
(Wat ik eventueel wel nog door de DB zou laten afhandelen, is het plaatsen van data in history-tabellen net voordat er een wijziging op een bepaald record gebeurt (dmv een trigger); maar verder ga ik niet).

Het is wat karig, maar in elk geval ben je niet zo erg als sommige Java ontwikkelaars die ik heb meegemaakt op een overheidsproject. Die hebben toen zelfs de FK constraints afgedwongen buiten de database.

In principe zou je kunnen stellen dat de manier waarop ik mijn data opsla, een implementatie detail is. Mijn applicatie (zowel UI als BL) hoeven niet te weten dat alles uiteindelijk in een SQL Server DB opgeslagen wordt. Het kan evengoed een Oracle DB zijn, of zelfs een set van XML bestanden.
Dit is vooral handig voor de unit-tests die ik heb. Ik wil bv niet dat mijn tests iedere keer naar de DB gaan om een bepaalde business-regel te testen. Ik voorzie hier dan gewoon een andere implementatie van mijn IRepository - interfaces.

Is testing dan voor jou echt het belangrijkste argument om voor deze constructie te kiezen? Dat is voor mij echt het laatste argument. Het belangrijkste lijkt mij dat de klant een product krijgt dat werkt volgens zijn specificaties, met een zo hoog mogelijke performance en robuustheid. Als het eenmaal op productie staat, doet het argument 'dat het zo lekker testbaar is' bijna nooit meer ter zake.

[whoami]

Gabberhead schreef op woensdag 05 november 2008 @ 11:55:
[...]

Aan de andere kant, waarom wil je los testen? In een goeie test neem je de hele stack mee inclusief de databank. Het kan wel zo zijn dat je logica alles doet wat je verwacht, maar dat er bij de insert op de tabel toch iets verkeerd gaat. Unit testing is ook niet heel gebruikelijk in de Oracle wereld op de manier zoals dat bijvoorbeeld in Java gebeurt. Ik test veel vaker 'alles wat er met de data gebeurt', dat is dus logica + DML.

Ik wil testen in een 'gecontroleerde' omgeving. Ik weet wat ik als input geef (dat definieer ik in mijn test), en ik weet wat ik als output wil hebben.

Het testen of het inserten van bepaalde objecten goed gaat, hoort dan weer in een andere test thuis,die niets met BL van doen heeft.
(Ja, daar heb ik ook tests voor ).
Echter, als ik wil weten of een algoritme die een bepaalde berekening uitvoert wel doet wat het moet doen, dan wil ik daarvoor echt niet naar de DB gaan.

Wat nu als er een nieuwe applicatie tegen dezelfde database gaat praten. Moet die ontwikkelaar het hele transactie mechanisme gaan herbouwen in zijn applicatie?

Dat transactie mechanisme zit niet in m'n applicatie.
In mijn applicatie zeg ik gewoon tegen een (infrastructuur) object: start nu een transactie. En commit of rollback nu een transactie.
Dat object gaat er dan wel voor zorgen dat er bv een transactie op de DB gestart wordt. Daar hoef ik me verder niets van aan te trekken.

Is testing dan voor jou echt het belangrijkste argument om voor deze constructie te kiezen? Dat is voor mij echt het laatste argument. Het belangrijkste lijkt mij dat de klant een product krijgt dat werkt volgens zijn specificaties, met een zo hoog mogelijke performance en robuustheid. Als het eenmaal op productie staat, doet het argument 'dat het zo lekker testbaar is' bijna nooit meer ter zake.

Testen en onderhoudbaarheid/aanpasbaarheid zijn voor mij de belangrijkste argumenten.
Ervoor zorgen dat de klant een robuust product krijgt, en het testen van dat product zijn 2 dingen die onlosmakelijk met elkaar verbonden zijn.
Je kan de klant geen robuust product geven, als het nooit (goed) getest geweest is.

Daarbij; je gaat me ook niet vertellen dat je al veel systemen gezien hebt die 10 jaar in productie draaien zonder dat er daarvoor één aanpassing/uitbreiding heeft moeten aan gebeuren.
Ook hier komt het 'testen' weer om de hoek kijken. De tests die je een tijd geleden geschreven hebt, zorgen er voor dat je zeker weet dat de vroegere functionaliteit werkt (of niet werkt).
En het helpt je ook bij het ontwikkelen van nieuwe functionaliteit.

Die unittests zijn er nl. niet alleen voor het testen ansich. Ze geven ook al een indicatie aan de ontwikkelaar hoe reeds bestaande code gebruikt moet worden bv.

Ow, enne, log4psql is een log-tool; da's geen test-tool.

[ Voor 4% gewijzigd door whoami op 05-11-2008 12:20 ]

[Confusion]

Gabberhead schreef op woensdag 05 november 2008 @ 11:55:
Wat nu als er een nieuwe applicatie tegen dezelfde database gaat praten. Moet die ontwikkelaar het hele transactie mechanisme gaan herbouwen in zijn applicatie?

Transacties omvatten over het algemeen meer dan alleen transactionele integriteit van de database. Er moet bijvoorbeeld state in de applicatie zelf bijgehouden worden en er moeten externe informatiebronnen aangepast worden. Als je dat soort dingen naar de "database" trekt, dan trek je in feite de complete applicatie naar PL/SQL. Maar als je de complete applicatie in PL/SQL schrijft, dan loop je tegen precies dezelfde (en meer) problemen aan als wanneer je het in Java, C# of desnoods PHP schrijft. Het is essentieel dat je een scheiding legt tussen wat de applicatie doet en wat de database doet. De database, met zijn stored procedures, bewaakt de integriteit van de data in de database. Niet meer en niet minder. Als je hem minder laat doen gebruik je de database niet goed, als je hem meer laat doen, dan ben je aan premature optimization aan het doen.

Dat iets in PL/SQL zich beter voor hergebruik laat lenen omdat het toevallig bij iedere database wordt meegeleverd is een drogredenering, waarbij je de eigenschappen van een kleine stored procedure automatisch toekent aan grote brokken code, alleen omdat ze in dezelfde taal geschreven zijn. Het grootste deel van de methodes is net zo specifiek voor jouw applicatie als de vergelijkbare Java of C#. Alleen bepaalde essentiele logica kan in herbruikbare stored procedures en triggers geprogrammeerd worden en dat zijn altijd kleine, beperkte hoeveelheden. Als je teveel naar PL/SQL trekt, had je kan net zo goed een JVM op de database server installeren en daar een Java RMI service op laten draaien, die diezelfde essentiele herbruikbare stored procedures aanroept. Met waarschijnlijk dezelfde performance.

Een webservice call in PL/SQL is een goede oplossing voor een performance probleem. Het is een slechte oplossing voor ieder ander probleem dat een webservice call vereist. We programmeren niet met z'n allen in Java en C# omdat PL/SQL zo fantastisch bruikbaar, testbaar en compleet is. Het 'SQL' zegt het al: het is een domeinspecifieke taal. Die zijn 99 van de 100 keer minder geschikt voor algemene problemen dan algemene talen.

[ Voor 16% gewijzigd door Confusion op 05-11-2008 13:06 ]

[wallyberk]

Een leuk topic, maar er word wel vaak vanuit een theorie gedacht.

Nu ben ik een DBA, maar persoonlijk heb wel voorkeur voor het strikt scheiden van de business laag en data laag, maar besef dat niet altijd kan/wenselijk is. Vaak zie je dat ervoor de kleine applicaties geen applicatie server wordt ingericht om deze overkill is. Denk hier aan applicaties van 10 of minder gebruikers. En dan is best te begrijpen dat je business logica in je database programmeert.

Voor de grotere omgevingen zie vaak dat je toch al een zware machine nodig hebt voor de database. En dan is offloaden van de business laag naar applicatie servers prettig. Zeker omdat deze beter schaalbaar is, dan de gemiddelde database.

Overgens heb vanuit een theoretische oogpunt eerder bezwaren met idee dat men de scheiding wil hebben om als enige reden dat men elke database onder de applicatie server zou willen zetten. Mijn bewaar is dat van 7 versies van SQL standaard ( Wikipedia: SQL ) er niet 1 volledig door alle database leveranciers wordt ondersteund ( zie http://troels.arvin.dk/db/rdbms/ ). Ik wil vaak van leveranciers die beweren database onafhankelijk te zijn een documentatie hebben wat zij wel en wat zij niet onder de "SQL standaard" verstaan.

Ook worden er vaak buiten de standaard SQL om opties aanboden die best de moeite waard zijn. Nu kan dat een keuze zijn om deze opties niet te gebruiken om database onafhankelijk te zijn, maar vaak zie je dat men wel alle mogelijkheden van een specifieke applicatie server willen gebruiken. Hierdoor verhuist je de vender lockin van de database naar de applicatie server.

[MBV]

Gabberhead schreef op woensdag 05 november 2008 @ 11:55:

Wat nu als er een nieuwe applicatie tegen dezelfde database gaat praten. Moet die ontwikkelaar het hele transactie mechanisme gaan herbouwen in zijn applicatie?

Dat lijkt mij een mooi moment om een webservice (of een ander mechanisme dat hetzelfde doet met een betere performance) te maken, en de externe applicatie daarmee te laten babbelen. Als je dan van database verandert (stel je voor, je wilt een vergelijkbaar systeem bij een andere klant neerzetten die op een ander platform werkt) hoef je weinig/niets aan te passen.

[...]

Het is wat karig, maar in elk geval ben je niet zo erg als sommige Java ontwikkelaars die ik heb meegemaakt op een overheidsproject. Die hebben toen zelfs de FK constraints afgedwongen buiten de database.

Moet je eens de database van een willekeurig ERP openen. Dynamics Navision, paar honderd tabellen, wat nou FK integrity? Of een willekeurige PHP-applicatie

Is testing dan voor jou echt het belangrijkste argument om voor deze constructie te kiezen? Dat is voor mij echt het laatste argument. Het belangrijkste lijkt mij dat de klant een product krijgt dat werkt volgens zijn specificaties, met een zo hoog mogelijke performance en robuustheid. Als het eenmaal op productie staat, doet het argument 'dat het zo lekker testbaar is' bijna nooit meer ter zake.

Jij doet niet aan regressie-testing? Kan serieus veel geld schelen op je onderhoudskosten.

Er zijn trouwens best wel situaties waarbij het best handig kan zijn, of betere performance kan leveren, om dingen naar de database te verhuizen. Maar in mijn ogen zijn dat de uitzonderingen.

@hierboven: er is een set functionaliteit die door de meeste databases wordt ondersteund: pak-em-beet Postgre, Oracle en MSSQL. de syntax verschilt misschien een klein beetje, maar vertalen is triviaal. Bij PL/SQL v.s. T-SQL voor business rules wordt dat een stuk lastiger.

[ Voor 7% gewijzigd door MBV op 05-11-2008 16:59 ]

[BCC]

MBV schreef op woensdag 05 november 2008 @ 16:56:
[...]
@hierboven: er is een set functionaliteit die door de meeste databases wordt ondersteund: pak-em-beet Postgre, Oracle en MSSQL. de syntax verschilt misschien een klein beetje, maar vertalen is triviaal. Bij PL/SQL v.s. T-SQL voor business rules wordt dat een stuk lastiger.

Daar gebruik je toch een database connector? Met iets van ODBC, JDBC en eventueel een activerecord variant ertussen.

Ik schrijf zelf bijna nooit meer SQL, alleen maar als er performance tweaks nodig zijn. De inhoud van de database bekijken e.d. doe ik tegenwoordig ook altijd via de commandline (ruby on rails), dan heb je ook gelijk je businesslaag erbij tussen zitten. En die is vaak een stuk handiger en gebruiksvriendelijker dan de SQL interface:

code:

Client.current.find(:all).collect(&:address)

of

SELECT * FROM clients c
LEFT JOIN addresses ON address.client_id = c.id
WHERE valid_to is NULL OR valid_to > CURDATE

Wat ik hier ook nog mis in de discussie is een stukje uniformiteit. Een Businesslogic laag dwing vaak een database struktuur af, wat erg fijn is als je een applicatie van een collega moet debuggen.

[ Voor 41% gewijzigd door BCC op 05-11-2008 18:19 ]

[Creepy]

wallyberk schreef op woensdag 05 november 2008 @ 16:50:
Een leuk topic, maar er word wel vaak vanuit een theorie gedacht.

Nu ben ik een DBA, maar persoonlijk heb wel voorkeur voor het strikt scheiden van de business laag en data laag, maar besef dat niet altijd kan/wenselijk is. Vaak zie je dat ervoor de kleine applicaties geen applicatie server wordt ingericht om deze overkill is. Denk hier aan applicaties van 10 of minder gebruikers. En dan is best te begrijpen dat je business logica in je database programmeert.

Wat heeft het scheiden van je business laag en data laag met een applicatieserver te maken? De scheiding kan ook puur in je code liggen.... Het scheiden van deze zaken wil niet automatisch zeggen dat er een extra server voor nodig is of dat er automatisch een (web)service o.i.d. voor zal moeten komen.

Voor de grotere omgevingen zie vaak dat je toch al een zware machine nodig hebt voor de database. En dan is offloaden van de business laag naar applicatie servers prettig. Zeker omdat deze beter schaalbaar is, dan de gemiddelde database.

Dat ben ik met je eens

Overgens heb vanuit een theoretische oogpunt eerder bezwaren met idee dat men de scheiding wil hebben om als enige reden dat men elke database onder de applicatie server zou willen zetten. Mijn bewaar is dat van 7 versies van SQL standaard ( Wikipedia: SQL ) er niet 1 volledig door alle database leveranciers wordt ondersteund ( zie http://troels.arvin.dk/db/rdbms/ ).

Je kan ook de uitzonderingen in de SQL standaard in code houden die de DB moet aanspreken, of deze code per RDMBS opzetten. Dat is wat mij betreft een stuk minder werk dan alle DB specifieke zaken (bijv de PL/SQL code) moeten porten.

Ik wil vaak van leveranciers die beweren database onafhankelijk te zijn een documentatie hebben wat zij wel en wat zij niet onder de "SQL standaard" verstaan.

Een beetje overtrokken reactie wat mij betreft. Het gaat erom of zij jullie DB ondersteunen, niks meer en niks minder. Meerdere DB's ondersteunen kan prima.

Ook worden er vaak buiten de standaard SQL om opties aanboden die best de moeite waard zijn. Nu kan dat een keuze zijn om deze opties niet te gebruiken om database onafhankelijk te zijn, maar vaak zie je dat men wel alle mogelijkheden van een specifieke applicatie server willen gebruiken. Hierdoor verhuist je de vender lockin van de database naar de applicatie server.

Dat je code kan schrijven die zonder enige check op alle RDMBS draait en toch van nieuwe mogelijkheden gebruikt maakt is (bijna?) onmogelijk. Maar je kan in je code prima rekening houden met meerdere RDMBS'en. Dat kan als de code *in* je RDMBS zit niet.

[ Voor 12% gewijzigd door Creepy op 05-11-2008 21:10 ]

[Confusion]

wallyberk schreef op woensdag 05 november 2008 @ 16:50:
Een leuk topic, maar er word wel vaak vanuit een theorie gedacht.

Ik vraag me af waarom dat idee leeft, want de meesten die reageren hebben behoorlijk wat praktijkervaring. Bovendien hebben een aantal helemaal geen theoretische achtergrond in de informatica.

[giMoz]

Leuk topic, en veel validaties kunnen wel in de database. maar dan doe je de aanname dat die nooit meer veranderd.
Stel nou eens dat je applicatie meerdere databases moet ondersteunen. Dan wil je niet al je logica 2x moeten schrijven.

(en vanuit eigen ervaring: als ik ooit nog een x een programmeur/DBA'er/Codeslaaf tegenkom die een HTTP XML request vanuit PL (of T) sql opzet kielhaal ik die ter plekke)

[MBV]

giMoz schreef op woensdag 05 november 2008 @ 21:10:

(en vanuit eigen ervaring: als ik ooit nog een x een programmeur/DBA'er/Codeslaaf tegenkom die een HTTP XML request vanuit PL (of T) sql opzet kielhaal ik die ter plekke)

Ik zou vast een schip en een touw zoeken, want Gabberhead is er zo een:

Gabberhead schreef op dinsdag 04 november 2008 @ 10:21:
Als je gaat vergelijken met externe systemen, hoef je die data toch helemaal niet over te gooien? DB-linkjes, webservices, enz...

Gabberhead schreef op woensdag 05 november 2008 @ 08:49:
En waarom moet je in godsnaam code dupliceren bij een aanroep van een webservice vanuit een stored procedure? Het externe systeem biedt een webservice aan en de stored procedure roept deze aan. Daar is helemaal niks anders aan in welke andere omgeving dan ook.

[NMe]

Gabberhead schreef op woensdag 05 november 2008 @ 08:49:
@-NMe: wat is er nou weer mis met applicaties die compleet in Forms draaien? Je opmerking is nogal laatdunkend, terwijl er genoeg bedrijven zijn die niks anders willen, gewoon omdat het simpel te gebruiken is, goed onderhoudbaar, goed performed en stabiel draait.

Ik weet dat het niet echt uit mijn post blijkt, maar ik doelde meer op de hele oude programma's die nog steeds onderhouden worden omdat het bedrijf geen zin heeft om het zaakje te laten herschrijven. Ik heb een tijd terug zelf moeten werken met de Oracle Forms developer, volgens mij een versie uit 2000, al weet ik dat niet meer zeker. Dingen die ineens versprongen als je wilde saven of zaken die er at runtime anders uitzagen dan toen je het formulier samenstelde waren niet van de lucht. En de eerste écht gebruikersvriendelijke Forms-applicatie moet ik nog tegenkomen, waarmee ik niet zeg dat dat onmogelijk is, maar wel dat het zonder daar veel moeite voor te doen niet vaak voorkomt.

bigbeng schreef op woensdag 05 november 2008 @ 08:26:

offtopic:
Met enigzins lede ogen heb ik deze discussie aangezien waarbij vijf mods/admins zich tegen 1 iemand keren.

offtopic:
Sorry, maar ik mag dus niet meer reageren in een discussietopic omdat ik toevallig een rood kleurtje heb? Ik ben ook gewoon een programmeur en ik heb ook gewoon een persoonlijke mening. Dat er hier nog tenminste 4 andere crewleden (en ervaren developers) rondlopen die het daarmee eens zijn zegt misschien wat, maar dat is niet de manier waarop ik mijn punt duidelijk wens te maken. Ik ben in de eerste instantie gewoon een user, net als jullie. Ik reageer niet als admin tenzij ik ook daadwerkelijk modrechten gebruik of aangeef dat ik als admin praat.

De reden dat ik zo fel reageer is dat hier ook mensen rondlopen die nog niet weten hoe alles werkt en hetgeen Gabberhead hier zegt voor waar aan gaan nemen. Ik heb bijvoorbeeld geen zin om over een jaar of vijf een applicatie te moeten gaan onderhouden die geschreven is volgens die principes die hier tentoongespreid worden.

[bigbeng]

offtopic:
Mijn laatste offtopic en dan is het echt genoeg: Er zit een verschil tussen reageren met loze on-liners of met inhoudelijke reacties. Ik mag toch hopen dat je dan met me eens bent dat tenminste 2 van jouw replies in deze topic wat karig zijn? En ja, ik vind dat het dan uitmaakt of je een kleurtje hebt of niet. En nou verdorie snel weer inhoudelijk op de topic gaan reageren!

[BCC]

Ik denk dat heel veel mensen gelijk "nee!" roepen omdat forms achtige applicaties snel uit de hand lopen.

Wat ik in de praktijk zie is dat het heel makkelijk om in Access, Oracle Forms, Filemaker Pro of Servoy een tooltje te maken. Dit wordt dan ook vaak gedaan door mensen die 'wel handig' zijn met dat soort zaken.

Het gebeurt alleen maar al te vaak dat dat soort tooltjes een crutiale rol gaan spelen in bedrijfsprocessen.
De tooltjes worden dan steeds complexer en ingewikkelder totdat het handige mannetje het niet meer kan en dan wordt er een professionele ITer bij gehaald.

Dat die een puinzooi aantreft is dan logisch, maar het is wat kort door de bocht om te zeggen dat Oracle Forms geen functie vervult.

Ik denk alleen dat veel 'professionele' ITers vaak met de nadelige effecten van de simpelheden van de oplossingen zijn geconfronteerd.

[Gabberhead]

Voordat dit topic nog verder ontaardt in een zinloze affakkeling van alles wat met Oracle te maken heeft, wil ik toch weer een beetje terug naar het onderwerp.
Ik wil alleen nog even zeggen dat enkele kritikasters zich nu ook een beetje belachelijk aan het maken zijn. Er zijn honderden, zo niet duizenden bedrijven die wel serieus met Forms bezig zijn. Een enkele verkeerde ervaring is niet representatief voor de gehele markt (anders zou ik als klant nooit meer met java-ontwikkelaars aan de slag willen...:P )

Om dit topic toch weer recht te trekken; de oorspronkelijke stelling was dat zoveel mogelijk logica door de database moet worden uitgevoerd. Dat wil ik even illustreren met een voorbeeld.

Er is een heel simpele tabel met 4 kolommen in Oracle: parameter, waarde, begin_datum, eind_datum. Hierop moet een GUI interface geschreven worden.
Business rules:
- PK is over de kolommen parameter en begin_datum
- eind_datum mag null zijn
- Een record is geldig als de referentiedatum ligt tussen begin_datum en eind_datum
- eind_datum moet groter zijn dan begin_datum
- 2 waardes van een parameter mogen elkaar niet overlappen in datum
- begin_datum en eind_datum mogen niet door de gebruiker handmatig worden ingevoerd

Ik wil nou wel eens weten hoe jullie dit zouden oplossen in een ideale praktijkomgeving. Dus met namen en rugnummers. Waar leg je de constraints, waar de rules en hoe los je het invoeren van de datums op?

Mijn variant zal ik later ook posten, om te voorkomen dat er alleen maar daar op geschoten wordt ipv. dat er voorbeelden komen

[.oisyn]

Een nutteloos voorbeeld. Ik zie hier namelijk niet echt domein logica terug, behalve wat validatie van velden, waarvan al werd gesteld dat dergelijke validatie best in een database (maar liefst niet alléén in die database) plaats mag vinden. De door jouw geopperde stelling was dan ook meer dat je onderhand je hele domein in je database moest gaan implementeren.

Ik weet wel een tegenvoorbeeld: een forum als deze. Tabeldefinities zijn verder niet zo interessant, het gaat om het abstracte model. Een user geeft het commando om in een bepaald topic een post te plaatsen (over dikke databases ). Laten we ons bij de dingen die moeten gebeuren beperken tot simpelweg een rechtencheck (mag je de user wel in de betreffende topic posten?) en het omzetten van linkjes naar andere topics op het forum (in tekstuele "http://" vorm) naar de betreffende [topic] tag, zodat het geheel als RML (de ubb-variant die hier gehanteerd wordt voor tekst-opmaak) in de database belandt.

Als ik de argumentatie die jij er in deze topic op nahoudt goed heb geïnterpreteerd beweer jij dus dat je al dat alles beter in de database kunt implementeren, want "business layer" is ook maar een marketing term (en onderdeel van de presentatie is het duidelijk níet)

[pedorus]

Gabberhead schreef op donderdag 06 november 2008 @ 20:36:
Er is een heel simpele tabel met 4 kolommen in Oracle: parameter, waarde, begin_datum, eind_datum. Hierop moet een GUI interface geschreven worden.
Business rules:
- PK is over de kolommen parameter en begin_datum
- eind_datum mag null zijn
- Een record is geldig als de referentiedatum ligt tussen begin_datum en eind_datum
- eind_datum moet groter zijn dan begin_datum
- 2 waardes van een parameter mogen elkaar niet overlappen in datum
- begin_datum en eind_datum mogen niet door de gebruiker handmatig worden ingevoerd

Ik wil nou wel eens weten hoe jullie dit zouden oplossen in een ideale praktijkomgeving. Dus met namen en rugnummers. Waar leg je de constraints, waar de rules en hoe los je het invoeren van de datums op?

Volgens mij is dit niet een valide case: de datums mogen niet handmatig worden ingevoerd en vervolgens vraag je hoe het invoeren van de datums wordt opgelost? Daarnaast heb ik het vermoeden dat eind_datum redundant is, en gelijk uit dit design moet. En dan nog de opmerkingen van .oisyn...

Voor de rest zou ik zeggen als beste gok, omdat ik geen idee heb over wat voor soort applicatie we het hebben, en wat de andere randvoorwaarden zijn:
Idealiter doe je de validatie gelijk zo dicht mogelijk bij de client: bijvoorbeeld in (gegenereerde) javascript, waarmee je ook de invoer regelt, daarna op de webserver omdat de client niet vertrouwd kan worden en je meerdere databases wil ondersteunen, en eventueel ook in de database als backup, maar daar kun je niet op vertrouwen omdat je meerdere databases wil kunnen supporten. Maar voor de schaalbaarheid ontlast je de database sowieso zoveel mogelijk, want webservers bijzetten is eenvoudiger. En je kan in dit voorbeeld maar het beste gebruik maken van je favoriete tools om die lagen in te vullen, omdat er niks bijzonders in zit... Ik ken meerdere proprietary tools die dit kunnen maken zonder dat er een regel handmatige code aan te pas komt.

[whoami]

Gabberhead schreef op donderdag 06 november 2008 @ 20:36:

Er is een heel simpele tabel met 4 kolommen in Oracle: parameter, waarde, begin_datum, eind_datum. Hierop moet een GUI interface geschreven worden.
Business rules:
- PK is over de kolommen parameter en begin_datum

Iew.
Je FK beslaat dus al 2 velden ?

- eind_datum mag null zijn
- Een record is geldig als de referentiedatum ligt tussen begin_datum en eind_datum
- eind_datum moet groter zijn dan begin_datum
- begin_datum en eind_datum mogen niet door de gebruiker handmatig worden ingevoerd

Tja, dat zijn allemaal wel dingen die je op DB niveau regelt (not null constraint, check constraint, check constraint, default), maar ik noem dit geen business logica ....

[MBV]

Ik dacht dat dat gebruikelijk was bij een tussentabel voor een many-to-many relatie? Sowieso wordt wel heel vaak een auto-increment-id of UUID toegepast als PK, terwijl er prima unieke velden beschikbaar zijn.

[NMe]

whoami schreef op donderdag 06 november 2008 @ 23:07:
[...]

Tja, dat zijn allemaal wel dingen die je op DB niveau regelt (not null constraint, check constraint, check constraint, default), maar ik noem dit geen business logica ....

My thoughts exactly. Als dát is wat Gabberhead business logic noemt, dan heeft 'ie gelijk, dat kan best in de database geregeld worden (en liever ook in je applicatie). Alleen is het dus niet wat ik versta onder business logic.

[pedorus]

whoami schreef op donderdag 06 november 2008 @ 23:07:
Iew.
Je FK beslaat dus al 2 velden ?

Het is geen FK maar een PK. Zolang er geen FK naartoe komt, zou ik het gewoon zo laten (aanpassen kan altijd nog).
Ik zou trouwens zoiets inderdaad bepaald geen "business rule" noemen.

[BCC]

-NMe- schreef op donderdag 06 november 2008 @ 23:43:
My thoughts exactly. Als dát is wat Gabberhead business logic noemt, dan heeft 'ie gelijk, dat kan best in de database geregeld worden (en liever ook in je applicatie). Alleen is het dus niet wat ik versta onder business logic.

Ik heb al die zaken eigenlijk ook al in een losse laag. Daarmee ben je volgens mij flexibeler. Bijvoorbeeld validaties die in soms gelden en soms niet, polymorfische relaties, bomen, representatie van data (naam van iemand opvragen bijvoorbeeld) etcetera.
Dit is wat de rest ook bedoelt met business-rules neem ik aan?

Ik heb alleen de auto increment trigger op het id veld staan.

[ Voor 10% gewijzigd door BCC op 07-11-2008 07:44 ]

[whoami]

pedorus schreef op donderdag 06 november 2008 @ 23:55:
[...]

Het is geen FK maar een PK. Zolang er geen FK naartoe komt, zou ik het gewoon zo laten (aanpassen kan altijd nog).

Da's wat ik bedoelde; als je een gerelateerde tabel hebt, ga je in die tabel die 2 velden van je PK moeten mee opnemen... Zowiezo ben ik voor surrogate pk's in de meeste gevallen, maar dat is een andere discussie. die hier trouwens al eens gevoerd geweest is

[Hydra]

Gabberhead schreef op donderdag 06 november 2008 @ 20:36:
Er is een heel simpele tabel met 4 kolommen in Oracle: parameter, waarde, begin_datum, eind_datum. Hierop moet een GUI interface geschreven worden.
Business rules:
- PK is over de kolommen parameter en begin_datum
- eind_datum mag null zijn
- Een record is geldig als de referentiedatum ligt tussen begin_datum en eind_datum
- eind_datum moet groter zijn dan begin_datum
- 2 waardes van een parameter mogen elkaar niet overlappen in datum
- begin_datum en eind_datum mogen niet door de gebruiker handmatig worden ingevoerd

Grappig dat bij bussiness rules meteen met een datadefinitie komt. Volgens mij begin je over het algemeen na te denken over wat iets functioneel moet gaan doen. DB constraints zijn technische zaken die in een technisch ontwerp staat, wat volgt uit een functioneel ontwerp.

[Anoniem: 259970]

.oisyn schreef op donderdag 06 november 2008 @ 21:15:
Een nutteloos voorbeeld. Ik zie hier namelijk niet echt domein logica terug, behalve wat validatie van velden, waarvan al werd gesteld dat dergelijke validatie best in een database (maar liefst niet alléén in die database) plaats mag vinden. De door jouw geopperde stelling was dan ook meer dat je onderhand je hele domein in je database moest gaan implementeren.

Ik weet wel een tegenvoorbeeld: een forum als deze. Tabeldefinities zijn verder niet zo interessant, het gaat om het abstracte model. Een user geeft het commando om in een bepaald topic een post te plaatsen (over dikke databases ). Laten we ons bij de dingen die moeten gebeuren beperken tot simpelweg een rechtencheck (mag je de user wel in de betreffende topic posten?) en het omzetten van linkjes naar andere topics op het forum (in tekstuele "http://" vorm) naar de betreffende [topic] tag, zodat het geheel als RML (de ubb-variant die hier gehanteerd wordt voor tekst-opmaak) in de database belandt.

Als ik de argumentatie die jij er in deze topic op nahoudt goed heb geïnterpreteerd beweer jij dus dat je al dat alles beter in de database kunt implementeren, want "business layer" is ook maar een marketing term (en onderdeel van de presentatie is het duidelijk níet)

Hier wil ik mij bij aansluiten. Naar mijn idee wordt een database 'vooral' gebruik voor de opslag van data. Wanneer er een controle moet zijn op basis van heel veel andere data, dan kan dit prima in de database. Maar over het algemeen probeer ik zoveel mogelijk in de software te maken. Meestal met een aparte "business logic layer".

[Gabberhead]

.oisyn schreef op donderdag 06 november 2008 @ 21:15:
Een nutteloos voorbeeld. Ik zie hier namelijk niet echt domein logica terug, behalve wat validatie van velden, waarvan al werd gesteld dat dergelijke validatie best in een database (maar liefst niet alléén in die database) plaats mag vinden. De door jouw geopperde stelling was dan ook meer dat je onderhand je hele domein in je database moest gaan implementeren.

Ik weet wel een tegenvoorbeeld: een forum als deze. Tabeldefinities zijn verder niet zo interessant, het gaat om het abstracte model. Een user geeft het commando om in een bepaald topic een post te plaatsen (over dikke databases ). Laten we ons bij de dingen die moeten gebeuren beperken tot simpelweg een rechtencheck (mag je de user wel in de betreffende topic posten?) en het omzetten van linkjes naar andere topics op het forum (in tekstuele "http://" vorm) naar de betreffende [topic] tag, zodat het geheel als RML (de ubb-variant die hier gehanteerd wordt voor tekst-opmaak) in de database belandt.

Als ik de argumentatie die jij er in deze topic op nahoudt goed heb geïnterpreteerd beweer jij dus dat je al dat alles beter in de database kunt implementeren, want "business layer" is ook maar een marketing term (en onderdeel van de presentatie is het duidelijk níet)

Rechten controleer je inderdaad aan de db kant. Daar waar ze vastgelegd liggen dus. Je wilt toch niet je usergegevens naar een andere laag halen om ze daar pas te controleren? Potentieel groot beveiligingslek.

Omzetten van linkjes naar tekst is geen business logica, maar een presentatiewens. En dat kan op tientallen verschillende manieren geregeld worden. Ook door zoveel mogelijk in de database te regelen. Ik ken genoeg grote websites met veelbezochte forums (nog wat meer dan Tweakers) die het zo regelen (http://technet.oracle.com http://asktom.oracle.com )

[ Voor 8% gewijzigd door Gabberhead op 08-11-2008 11:34 ]

[Gabberhead]

pedorus schreef op donderdag 06 november 2008 @ 21:56:
[...]

Volgens mij is dit niet een valide case: de datums mogen niet handmatig worden ingevoerd en vervolgens vraag je hoe het invoeren van de datums wordt opgelost? Daarnaast heb ik het vermoeden dat eind_datum redundant is, en gelijk uit dit design moet. En dan nog de opmerkingen van .oisyn...

Voor de rest zou ik zeggen als beste gok, omdat ik geen idee heb over wat voor soort applicatie we het hebben, en wat de andere randvoorwaarden zijn:
Idealiter doe je de validatie gelijk zo dicht mogelijk bij de client: bijvoorbeeld in (gegenereerde) javascript, waarmee je ook de invoer regelt, daarna op de webserver omdat de client niet vertrouwd kan worden en je meerdere databases wil ondersteunen, en eventueel ook in de database als backup, maar daar kun je niet op vertrouwen omdat je meerdere databases wil kunnen supporten. Maar voor de schaalbaarheid ontlast je de database sowieso zoveel mogelijk, want webservers bijzetten is eenvoudiger. En je kan in dit voorbeeld maar het beste gebruik maken van je favoriete tools om die lagen in te vullen, omdat er niks bijzonders in zit... Ik ken meerdere proprietary tools die dit kunnen maken zonder dat er een regel handmatige code aan te pas komt.

Ik had m'n case nog iets verder moeten beschrijven zie ik, excuus.
Ik vergat even te zeggen dat een update op de data moet zorgen voor een nieuw record met begin_datum op sysdate, waarbij het oude record wordt gesloten met een eind_datum op sysdate - 1.
Een delete zorgt voor het sluiten van het record met eind_datum op sysdate - 1.
Op deze manier wordt historie bijgehouden zonder extra journalling tabel voor kleine parameter tabelletjes. Eind_datum is in dit voorbeeld dus niet redundant.

Jouw antwoord geeft me overigens de rillingen. Ik zie dat je de validatie in 3(!) verschillende lagen wilt inbouwen. Je bent dus 3(!) keer dezelfde functionaliteit aan het herbouwen. Dat is behalve 3 keer teveel werk ook nog eens niet onderhoudbaar. Een wijziging in het datamodel of de business rules zorgt voor een aanpassing op 3(!) plaatsen.

En validaties in je javascript? Dat is dus een roundtrip per ingevoerd veld of record voor elke validatie? Lijkt me niet best voor de performance.

[mphilipp]

Interessante discussie...Leuk om te zien dat velen lekker vasthouden aan allerlei dogma's

Ik heb een heel praktisch bezwaar tegen (alle) business logic in de app. En dat is iets dat ik al zo vaak heb zien gebeuren, en wat tot zeer grote problemen leidt vwb dataintegriteit. Ik heb nl meer dan eens gewerkt aan applicaties die herbouwd werden in (in mijn geval) Oracle en die voorheen op een of ander mainframe stonden. Lekker alle logica in de app. Mooi, dus als we een programma 'schroevendraaier' maken, kunnen we lekker buiten al die lastige controles om de data verkrachten. Dat gebeurt dus gewoon. Gevolg: inconsistente data, foute data en dus grote problemen bij data migratie, want je moet op een of andere manier die (half) foute klanten over krijgen en je wilt niet die foute data overnemen in je gloednieuwe database.
Sowieso is het onwenselijk dat er foute data in een database kan voorkomen. Vandaar dat ik minimaal referentiele integriteit wil afdwingen, maar ook in ieder geval de basale business rules.
Als je analyse een beetje kosjer is, en die wijst uit dat item x binnen bepaalde grenzen moet vallen, zou ik dat lekker in de db stoppen. Waarom moet je die ellende in elk scherm gaan bouwen die in je app voorkomt? Tuurlijk, je kunt met oo werken waar je de boel maar 1 keer hoeft te kloppen, maar als je met verschillende kanalen werkt, kan het best voorkomen dat je dezelfde ellende 2x moet implementeren.
Data integriteit is een van de grootste problemen die ik in de afgelopen 20 jaar ben tegen gekomen. Onvoorstelbaar hoe dom bepaalde bedrijven zijn, dat ze dus gewoon toestaan dat een verkeerd ingevoerde klant met de hand, buiten de app om, aangepast mag worden (want het is zoveel werk om 'm eruit te kiepen en opnieuw op te voeren).

Nee, ik ben van mening dat je die dingen in de db moet afdwingen. Je weet dan in ieder geval zeker dat de foute data niet de db in komt, en dat niet een of andere leip met TOAD of Acces of wat dan ook de boel gaat lopen verzieken. Je kunt debatteren over hoe ver je daarin moet gaan, en of de app dus in zekere zin 'dom' is en alleen formaatcontroles doet, of dat ie toch bepaalde complexe zaken checkt. Maar - ik ben Oracle floeperd - als je met Oracle werkt is het toch doorgaans een kwestie van stored procedures/functions die je vanuit de app aanroept als je de checks vanuit de app wilt doen. Tsja...dan kun je ze ook vanuit de db aan laten roepen door triggers.

En nee, dat is idd niet portable, maar er zijn niet zo gek veel bedrijven die plotseling besluiten dat ze van Oracle naar SLQ Server gaan. Generieke database applicaties heb ik niet zo gek veel gezien, maar dat komt omdat ik geen onwikkelaar meer ben, en er nu eea is verandert wat SQL betreft. Voorheen was het gewoon niet mogelijk om zomaar SQL statements uit Oracle op SQL Server te draaien door de afwijkende syntax van joins, outer joins enzo. Nu is de syntax in Oracle aangepast aan de nieuwste standaard en zou het wel mogelijk moeten zijn om generieke db apps te ontwikkelen. Vroegâh moest je dan teveel consessies doen en werdt het rete-traag.

[Gomez12]

Gabberhead schreef op zaterdag 08 november 2008 @ 11:20:
[...]
Omzetten van linkjes naar tekst is geen business logica, maar een presentatiewens. En dat kan op tientallen verschillende manieren geregeld worden. Ook door zoveel mogelijk in de database te regelen. Ik ken genoeg grote websites met veelbezochte forums (nog wat meer dan Tweakers) die het zo regelen (http://technet.oracle.com http://asktom.oracle.com )

Tja dan verschillen jij en ik van mening over presentatie wensen.
Het omzetten van linkjes etc is een stukje business logica wat misschien alleen gebruikt wordt in de viewlaag, maar het is imho geen onderdeel van de viewlaag.

Imho heb je een brok data en als je die anders wilt tonen dan heb je daar nog een laag tussen, ziedaar je business logica.

Zoals jij het stelt ga je volgens mij in de problemen komen als je met dezelfde data en dezelfde viewlaag toch een iets ander resultaat wilt hebben ( bijv extra icoontjes bij mods )

[Gomez12]

mphilipp schreef op zaterdag 08 november 2008 @ 12:00:
Ik heb een heel praktisch bezwaar tegen (alle) business logic in de app.
[snip]
Lekker alle logica in de app. Mooi, dus als we een programma 'schroevendraaier' maken, kunnen we lekker buiten al die lastige controles om de data verkrachten. Dat gebeurt dus gewoon. Gevolg: inconsistente data, foute data

Sorry hoor, maar de integriteit van de data is natuurlijk wel de verantwoordelijkheid van de db.
De data kan volgens ingewikkelde business rules misschien fout zijn, maar simpel gezegd kan je geen reply hebben zonder topic, dat hoort je db te controleren...

Vandaar dat ik minimaal referentiele integriteit wil afdwingen, maar ook in ieder geval de basale business rules.

En daar ga je je al op een hellend vlak begeven, je gaat je business rules dus versnipperen. Als je dit erg basaal doet is het nog niet zo'n ramp.

Waarom moet je die ellende in elk scherm gaan bouwen die in je app voorkomt? Tuurlijk, je kunt met oo werken waar je de boel maar 1 keer hoeft te kloppen, maar als je met verschillende kanalen werkt, kan het best voorkomen dat je dezelfde ellende 2x moet implementeren.

Dan doe je het gewoon verkeerd. Schermen zijn alleen viewlogica.
Je business logica moet voor je viewlogica zitten zodat als je met verschillende kanalen werkt je business logica altijd hetzelfde blijft, alleen je viewlaag is anders...

En nee, dat is idd niet portable, maar er zijn niet zo gek veel bedrijven die plotseling besluiten dat ze van Oracle naar SLQ Server gaan.

Maar er zijn wel redelijk veel bedrijven die al een dbase server hebben staan en geen zin in een 2e hebben...

Voorheen was het gewoon niet mogelijk om zomaar SQL statements uit Oracle op SQL Server te draaien door de afwijkende syntax van joins, outer joins enzo. Nu is de syntax in Oracle aangepast aan de nieuwste standaard en zou het wel mogelijk moeten zijn om generieke db apps te ontwikkelen. Vroegâh moest je dan teveel consessies doen en werdt het rete-traag.

Dan praat je alleen maar over enkele kleine aanpassingen. Eventjes je complete pl/sql porten is iets meer werk dan enkele syntax verschillen...

Sowieso krijg ik het idee dat de oracle mensen hier te veel logica in de viewlaag bouwden en dat die nu blij zijn dat ze dit in pl/sql kwijt kunnen. Terwijl ik al jarenlang met een business laag werk wat imho hetzelfde principe hanteert als pl/sql alleen is dit wel een 100% fullblown programmeertaal.

Voor mij zou het argument van de oracle mensen alleen opgaan als je echt alles behalve viewlogica in pl/sql gaat maken ( waardoor het geen onderdeel meer van de db is, maar gewoon een andere progtaal ). Maar dan heb ik het vermoeden dat je wat functionaliteiten gaat missen.

Als je meer dan viewlogica buiten pl/sql moet maken dan versnipper je imho alleen maar de code en creeer je een vendor lock die helemaal niet nodig is.

[mphilipp]

Gomez12 schreef op zaterdag 08 november 2008 @ 12:49:
[...]
Sorry hoor
[en dan een verhaal]

Als je mijn verhaal goed leest, zie je dat we het eigenlijk eens zijn. Waar ik nuance aanbreng, zoals in 'minimaal bladibla...' maak jij er op een of andere manier van dat ik zeg dat ik dat maximaal wil. Een beetje beter lezen aub. En zo ga je eigenlijk de hele tijd verder.
Ik pleit niet voor een versnippering, maar in ieder geval voor een minimum in de database. Over bepaalde business logica kun je nog debatteren of het hier of daar moet, maar zodra ze de integriteit en validiteit van de gegevens raken, vind ik dat ze in de database moeten.
Maar uiteindelijk staat er niets in steen. Soms kom je gewoon een situatie tegen dat het niet anders kan of niet gewenst is om in de db te stoppen. Soms is er dus gewoon een hele goede reden om het juist wél of juist niet te doen. In zo'n geval moet je er niet te krampachtig mee omgaan.

Dan praat je alleen maar over enkele kleine aanpassingen. Eventjes je complete pl/sql porten is iets meer werk dan enkele syntax verschillen...

Ik heb het over SQL. Ik wéét wat PL/SQL is, en dat heb ik niet genoemd.

Sowieso krijg ik het idee dat de oracle mensen hier te veel logica in de viewlaag bouwden en dat die nu blij zijn dat ze dit in pl/sql kwijt kunnen. Terwijl ik al jarenlang met een business laag werk wat imho hetzelfde principe hanteert als pl/sql alleen is dit wel een 100% fullblown programmeertaal.

Ik weet niet welke ervaring je met Oracle hebt, maar dat is een beetje vage uitstpraak. Als je het over heel vroeger hebt, toen er nog geen constraints. triggers en PL/SQL was, hadden we vrij weinig keuze... Je moest wel, maar sinds die dingen er zijn, wordt het naar mijn idee allemaal vrolijk in de db gestopt. In Nederland wordt/werd er bovendien nog redelijk veel met Designer gewerkt, waar je de keuze had om bepaalde logica aan beide kanten te implementeren (of alleen in de app, of alleen in de db, maar ook beide). Hij genereerde dan de code. Voordeel van een bepaalde controle in de app is dat ie sneller is, en in de db voorkom je dat er tóch via een omweg ellende in de db komt.

Voor mij zou het argument van de oracle mensen alleen opgaan als je echt alles behalve viewlogica in pl/sql gaat maken ( waardoor het geen onderdeel meer van de db is, maar gewoon een andere progtaal ). Maar dan heb ik het vermoeden dat je wat functionaliteiten gaat missen.

Wat zijn 'Oracle mensen'? Is dat een ander ras ofzo?
Volgens mij zijn er zat apps die zo ontwikkeld zijn, zonder functionaliteit te missen. Als ik tenminste goed begrijp wat je bedoelt, want het klinkt een beetje vaag. Oracle is wat dat betreft echt niet anders dan andere systemen. Je kunt bovendien ook nog stored procedures in Java maken, in case je iets wilt wat niet zonder meer in PL/SQL kan. Maar ik ben benieuwd wat dat dan allemaal is.

[ Voor 49% gewijzigd door mphilipp op 08-11-2008 13:20 ]

[Creepy]

Ik denk dat we de discussie over data integriteit e.d. niet hoeven te voeren. Dat de DB dit minimaal moet doen zijn de meeste het wel over eens denk. Het topic gaat toch echt over business logica in je DB, niet om pure data integriteit. Data integriteit en business logica overlappen elkaar maar zijn niet hetzelfde.

Ik krijg eerlijk gezet het gevoel dat er mensen zijn die denken dat een extra laag automatisch performance verlies, extra services (of zelfs servers) zou moeten betekenen. Klopt mijn gevoel? Dit is absoluut niet waar namelijk.

Wat mij opvalt is dat de mensen die er voor zijn om dat in de DB te doen nagenoeg allemaal met Oracle werken en blijkbaar bij 1 bedrijf zitten of software schrijven voor 1 bedrijf. Als je dit eens niet meeneemt maar bijv. software zou moeten schrijven die bij een willekeurig bedrijf in zou moeten zetten, denken jullie er dan nog zo over dat alle business logica in de DB moet?

Dat is dus een roundtrip per ingevoerd veld of record voor elke validatie? Lijkt me niet best voor de performance.

Jij doet precies hetzelfde. Voor elke validatie maak je een roundtrip naar de DB Omdat te voorkomen zorg je dus ook dat je UI laag bepaalde validaties kan maken om die roundtrip te voorkomen. Het valt verder ook mij op dat de case die je beschrijft weinig echte business rules bevatten, maar dat het meer dataintegriteit is. Een echte case met business rules beschrijf je 9 van de 10 keer zonder datamodel. Het datamodel zou vanzelf moeten volgen a.d.h.v. de wensen en eisen van de klant.

Het is in een DB laag een kleine moeite om met afwijkende syntax van verschillende RDBMS'en rekening te houden. Dit wordt dan ook bedoeld met "generiek". Er wordt niet mee bedoelt dat er 1 SQL statement wordt geschreven/gegenereerd die op alle DB's werkt. Dat kan niet in alle gevallen en kan inderdaad nadelig werken voor je permance. Ik het het idee dat de de voorstanders van de dikke DB dit niet inzien....

offtopic:
Overigens valt het me ook op dat sommige replies of delen van replies totaal genegeerd worden......

[pedorus]

Gabberhead schreef op zaterdag 08 november 2008 @ 11:20:
Rechten controleer je inderdaad aan de db kant. Daar waar ze vastgelegd liggen dus. Je wilt toch niet je usergegevens naar een andere laag halen om ze daar pas te controleren? Potentieel groot beveiligingslek.

Er is dus ook een geëncrypte verbinding tussen de DB en de client? Want anders gaat dit natuurlijk weinig zin hebben. Hoe gaat dit precies in zijn werk?

Ik ken genoeg grote websites met veelbezochte forums (nog wat meer dan Tweakers) die het zo regelen (http://technet.oracle.com http://asktom.oracle.com )

Ik kan oracle niet vinden... Ik vraag me ook af hoe goed zo'n 'alles in de db'-oplossing schaalt. Tweakers staat nu op plek 50.

Gabberhead schreef op zaterdag 08 november 2008 @ 11:29:
Eind_datum is in dit voorbeeld dus niet redundant.

Mm, het is dus een simpel logbestand. Maar dan nog kun je verwijderen van een parameter gewoon zien als het op NULL zetten van de waarde vanaf een bepaalde datum, en heb je dus geen eind_datum nodig.

Jouw antwoord geeft me overigens de rillingen. Ik zie dat je de validatie in 3(!) verschillende lagen wilt inbouwen. Je bent dus 3(!) keer dezelfde functionaliteit aan het herbouwen. Dat is behalve 3 keer teveel werk ook nog eens niet onderhoudbaar. Een wijziging in het datamodel of de business rules zorgt voor een aanpassing op 3(!) plaatsen.

En validaties in je javascript? Dat is dus een roundtrip per ingevoerd veld of record voor elke validatie? Lijkt me niet best voor de performance.

Controleren of een veld aan een bepaald patroon voldoet (bijvoorbeeld of het een valide datum is) heb je echt geen round-trip voor nodig. De grap is trouwens dat de door jou aangehaalde Toon Koppelaars ook validaties in Javascript doet (en het dus blijkbaar ook op 2(!!!) plekken heeft). Dat validatie (bijvoorbeeld of iets echt een datum is) op 3 plekken gebeurd, betekent niet dat je het ook handmatig 3x schrijft. En bij handmatige aanpassingen van de code wordt alleen het gegenereerde deel van de code aangepast, niet de extra toevoegingen. Dat kan bijvoorbeeld met partial classes.

[Creepy]

mphilipp schreef op zaterdag 08 november 2008 @ 12:00:
Interessante discussie...Leuk om te zien dat velen lekker vasthouden aan allerlei dogma's

Die dogmas komen ook in jouw post flink naar voren (ja, we zijn er beiden schuldig aan )

In het kort over je post: als je rules e.d. in je DB wilt afvangen omdat niemand dan met TOAD o.i.d. in je DB gaat zitten rommelen dan heb je wat mij betreft een totaal ander probleem: een gebruiker die blijkbaar met TOAD direct bij de DB kan en handmatig kan gaan rommelen. Dat gooit automatisch je SP's overboord (want die roept de gebruiker via TOAD niet aan) en hangt alles in 1 keer af van je triggers. Wil je nu echt beweren dat het verstandig is om je volledige business logica in triggers te gaan stoppen?

Ik zou ze liever op een andere plek stoppen zodat je die code kan hergebruiken voor het afdwingen ervan, het controleren van de data en het eventueel rechttrekken indien nodig. Doe code kan dan ook nog eens zo worden geschreven dat het voor meerdere backends (Oracle, SQL server, whatever) werkt of in elk geval uit te breiden is naar meerdere backends. Nee dat is niet nodig als je je app (of code) schrijft voor 1 specifieke klant (alhoewel....) maar dat doe ik dan ook niet

[ Voor 22% gewijzigd door Creepy op 08-11-2008 13:29 ]

[mphilipp]

Creepy schreef op zaterdag 08 november 2008 @ 13:18:
Wat mij opvalt is dat de mensen die er voor zijn om dat in de DB te doen nagenoeg allemaal met Oracle werken en blijkbaar bij 1 bedrijf zitten of software schrijven voor 1 bedrijf.

Ik ben al 20 jaar met Oracle bezig als huurling en heb bij de grootste Oracle gebruikers van Nederland opdrachten uitgevoerd (niet in mijn eentje uiteraard). Ik spreek dus niet vanuit 1 situatie, maar over verschillende 'enterprise' applicaties. Hardly obscure ervaring zou ik zeggen.

[Creepy]

Van de term "enterprise" krijg ik rillingen (wat mij betreft ook zo'n loze marketing term, het zegt namelijk helemaal niks). En dan ben ik inderdaad wel benieuwd hoeveel van die applicaties bij meerdere klanten draaien en waarom jullie afdwingen dat er maar Oracle gebruikt moet worden? Want Oracle blijft de gemene deler bij alle bedrijven blijkbaar. Je blijft namelijk vast zitten aan 1 specifiek RDMBS (en vaak ook nog eens 1 specifieke versie daarvan.....).
Of je maakt software op het moment dat een bedrijf bij jullie aanklopt, dus schrijf je die software in de eerste plaats maar voor 1 bedrijf..... of zie ik dat verkeerd?

[ Voor 40% gewijzigd door Creepy op 08-11-2008 13:34 ]

[Gomez12]

mphilipp schreef op zaterdag 08 november 2008 @ 13:02:
[...]

Als je mijn verhaal goed leest, zie je dat we het eigenlijk eens zijn. Waar ik nuance aanbreng, zoals in 'minimaal bladibla...' maak jij er op een of andere manier van dat ik zeg dat ik dat maximaal wil. Een beetje beter lezen aub. En zo ga je eigenlijk de hele tijd verder.

Misschien dat het komt doordat de TS voorstaat om zoveel mogelijk logica in je db te gooien en jij ook begint met : Ik heb een heel praktisch bezwaar tegen (alle) business logic in de app.

Dat er in de praktijk nog 100'en tussenvormen zijn is leuk en goed, maar voor de discussie is het imho wel zo makkelijk om het redelijk simplistisch te houden.

[...]
Ik heb het over SQL. Ik wéét wat PL/SQL is, en dat heb ik niet genoemd.

Ok, dan interpreteerde ik het verkeerd. Ik had het idee dat je het had over business logica ( daar gaat het topic namelijk over ).

[...]
Wat zijn 'Oracle mensen'? Is dat een ander ras ofzo?
Volgens mij zijn er zat apps die zo ontwikkeld zijn, zonder functionaliteit te missen. Als ik tenminste goed begrijp wat je bedoelt, want het klinkt een beetje vaag.

Imho praktisch wel als zij alle business logica in de dbase willen zetten.
Wat ik bedoel is dat als TS alle business logica in de dbase wil zetten dat hij dan gewoon keihard halve apps zit te programmeren in pl/sql ipv in een "standaard" programmeertaal, en dan vermoed ik dat je functionaliteit in pl/sql gaat missen.

Net zoals het imho ook niet verstandig is om stored procedures in java te maken ( dbase is hier beter in ) is het imho ook niet handig om alle business logica in je dbase te programmeren ( programmeertaal is hier breder in ).

Natuurlijk is er ergens een ideale balans tussen code in dbase en code in progtaal, maar als ik moet kiezen tussen alle code in dbase of alle code in programmeertaal en alleen de data in dbase dan kies ik toch voor het laatste...

mphilipp schreef op zaterdag 08 november 2008 @ 13:28:
[...]
Ik ben al 20 jaar met Oracle bezig als huurling en heb bij de grootste Oracle gebruikers van Nederland opdrachten uitgevoerd (niet in mijn eentje uiteraard). Ik spreek dus niet vanuit 1 situatie, maar over verschillende 'enterprise' applicaties. Hardly obscure ervaring zou ik zeggen.

Geinteresseerde vraag, ben je ook weleens betrokken geweest bij het sales gedeelte waar een mogelijke klant aangaf wel al mssql te hebben maar geen oracle en dit ook niet te willen aanschaffen?
Waardoor je dus gewoon een sale het gemist.

Want als de situatie altijd is dat de klant al oracle heeft dan kan ik jouw TS zijn argumentatie wel begrijpen, maar het zegt imho erg weinig over werkwijzen in algemene dbases hooguit iets over werkwijzen in oracle dbases...

Correctie uitgevoerd op jouw naar TS, ik begreep mphilipp even verkeerd

[ Voor 18% gewijzigd door Gomez12 op 08-11-2008 13:53 ]

[mphilipp]

Creepy schreef op zaterdag 08 november 2008 @ 13:27:
[...]
Die dogmas komen ook in jouw post flink naar voren (ja, we zijn er beiden schuldig aan )

Geen dogma's. Dogma's kunnen niet bediscussiëerd worden. Ik wil best een boompje opzetten over wat waar moet. Als de reden goed genoeg is, moet je kunnen afwijken van 'regels' of voorschriften.

In het kort over je post: als je rules e.d. in je DB wilt afvangen omdat niemand dan met TOAD o.i.d. in je DB gaat zitten rommelen dan heb je wat mij betreft een totaal ander probleem: een gebruiker die blijkbaar met TOAD direct bij de DB kan en handmatig kan gaan rommelen. Dat gooit automatisch je SP's overboord (want die roept de gebruiker via TOAD niet aan) en hangt alles in 1 keer af van je triggers. Wil je nu echt beweren dat het verstandig is om je volledige business logica in triggers te gaan stoppen?

Ja.
Ik heb het trouwens niet over simpele gebruikers die met TOAD de database te lijf gaan, maar applicatie beheerders of zelfs DBA's (afhankelijk hoe eea bij een bedrijf is geregeld) die wordt verzocht om data aan te passen. Dat gebeurt vaker dan je denkt.
Maar je doet of ik heel dogmatisch eis dat alles in die db zit. Dat is niet zo. Ik wil wel graag een bepaald minimum in die database hebben, en dan gaat het om zaken die met de correctheid van de data te maken hebben. Ik heb gewoon teveel ellende gezien doordat men als een kip zonder kop nieuwe programma's aan het systeem toevoegde (of ergens anders in de organisatie die op dezelfde data werkte) of zaken veranderde, zonder rekening te houden met de bestaande situatie. Allemaal heel dom en zo hoort het niet, maar feit is dat het gewoon gebeurt. Ik wil dus graag dat het systeem netjes blijft.

Laten we zeggen dat ik iets te vaak systemen ben tegen gekomen waar men hele pakken controlelijstjes en rapportjes had om te checken of alles nog kosjer was. Dat is iets dat ik pertinent weiger te maken natuurlijk.

[Creepy]

mphilipp schreef op zaterdag 08 november 2008 @ 13:45:
[...]

Geen dogma's. Dogma's kunnen niet bediscussiëerd worden. Ik wil best een boompje opzetten over wat waar moet. Als de reden goed genoeg is, moet je kunnen afwijken van 'regels' of voorschriften.

Eens

Ja.
Ik heb het trouwens niet over simpele gebruikers die met TOAD de database te lijf gaan, maar applicatie beheerders of zelfs DBA's (afhankelijk hoe eea bij een bedrijf is geregeld) die wordt verzocht om data aan te passen. Dat gebeurt vaker dan je denkt.

I know.. helaas...

Maar je doet of ik heel dogmatisch eis dat alles in die db zit. Dat is niet zo. Ik wil wel graag een bepaald minimum in die database hebben, en dan gaat het om zaken die met de correctheid van de data te maken hebben. Ik heb gewoon teveel ellende gezien doordat men als een kip zonder kop nieuwe programma's aan het systeem toevoegde (of ergens anders in de organisatie die op dezelfde data werkte) of zaken veranderde, zonder rekening te houden met de bestaande situatie. Allemaal heel dom en zo hoort het niet, maar feit is dat het gewoon gebeurt. Ik wil dus graag dat het systeem netjes blijft.

Laten we zeggen dat ik iets te vaak systemen ben tegen gekomen waar men hele pakken controlelijstjes en rapportjes had om te checken of alles nog kosjer was. Dat is iets dat ik pertinent weiger te maken natuurlijk.

Ik kan niet anders dan het met je eens zijn behalve met je volmondig "ja" op mijn vraag of alle business logica in de DB moet zitten. Er is wat mij betreft een verschil tussen business rules en data integriteit.

[ Voor 5% gewijzigd door Creepy op 08-11-2008 13:52 ]

[mphilipp]

Gomez12 schreef op zaterdag 08 november 2008 @ 13:41:
[...]
Ok, dan interpreteerde ik het verkeerd. Ik had het idee dat je het had over business logica ( daar gaat het topic namelijk over ).

Tjsa...laat maar ook. Misschien moet je nog eens goed lezen in welk verband ik dat noemde.

Imho praktisch wel als zij alle business logica in de dbase willen zetten.
Wat ik bedoel is dat als TS alle business logica in de dbase wil zetten dat hij dan gewoon keihard halve apps zit te programmeren in pl/sql ipv in een "standaard" programmeertaal, en dan vermoed ik dat je functionaliteit in pl/sql gaat missen.

Welke dan?
Business logic is toch niet zo ingewikkeld dat het niet in PL/SQL zou kunnen?
Maar nogmaals: ik ben niet zo dogmatisch dat ik 100% erin wil hebben. Als iets niet praktisch is om in de db te stoppen, moet je dat niet doen. Ik heb er geen problemen mee om het deels in de db en deels in de app te doen. Niets mis mee. Je moet een taal gebruiken die het meest geschikte is voor een bepaalde taak. En iets als PL/SQL is prima geschikt voor dit soort zaken. Uiteraard zijn er best problemen die je er minder goed mee kunt oplossen, maar dat zal hooguit 5% van je code zijn. Nou, doe je dat lekker in de app. Wat is het probleem daarmee? Versnippering? 100% scheiding is denk ik toch niet vol te houden en als iets logisch en/of praktisch gezien op zijn plek is in de app, moet je het daarin zetten.

Natuurlijk is er ergens een ideale balans tussen code in dbase en code in progtaal, maar als ik moet kiezen tussen alle code in dbase of alle code in programmeertaal en alleen de data in dbase dan kies ik toch voor het laatste...

Prima, iedereen heeft zo zijn eigen voorkeuren.
Met business logica hoef ik geen plaatjes te tekenen of schermpjes op te bouwen. Ik ben dus benieuwd welke magische programmeertaal beter geschikt is om die ellende in te programmeren. Ik zeg niet dat (bijvoorbeeld) PL/SQL (maar SQL Server heeft ook een dergelijk ding) de meest perfecte taal is, maar hij is wel ontwikkeld (gebasseerd op ADA) voor dit soort toepassingen. Er zijn meerdere wegen die naar Rome leiden, maar ik ben niet vaak in een situatie gekomen dat iets op dat gebied niet kon met PL/SQL.

[ Voor 3% gewijzigd door mphilipp op 08-11-2008 14:00 ]

[Gomez12]

mphilipp schreef op zaterdag 08 november 2008 @ 13:59:
[...]
Welke dan?
Business logic is toch niet zo ingewikkeld dat het niet in PL/SQL zou kunnen?

Als je het alleen over primaire business logic hebt valt dit waarschijnlijk prima te doen. Alleen creer je er dan een codepunt bij ( je krijgt dan dbase - pl/sql - app - viewdingen ).

[...]
Met business logica hoef ik geen plaatjes te tekenen of schermpjes op te bouwen.

Maar ik vind bijv de afhandeling van missende gegevens ( is het 0, null of een gemiddelde van de dichstbijzijnde waardes ) wel business logica wat waarschijnlijk onderdeel is van de viewlogica. ( het is alleen boeiend tijdens het viewen, maar hoe je het behandelt is wel een vaste regel )

[NMe]

Gabberhead schreef op zaterdag 08 november 2008 @ 11:20:
[...]


Rechten controleer je inderdaad aan de db kant. Daar waar ze vastgelegd liggen dus. Je wilt toch niet je usergegevens naar een andere laag halen om ze daar pas te controleren? Potentieel groot beveiligingslek.

Omzetten van linkjes naar tekst is geen business logica, maar een presentatiewens. En dat kan op tientallen verschillende manieren geregeld worden. Ook door zoveel mogelijk in de database te regelen. Ik ken genoeg grote websites met veelbezochte forums (nog wat meer dan Tweakers) die het zo regelen (http://technet.oracle.com http://asktom.oracle.com )

Jammer dat je maar op één van zijn voorbeelden ingaat. De stackbased parser die we hier gebruiken voor het parsen van RML krijg je misschien ook wel in je databasesysteem geprogrammeerd met PL/SQL, maar je maakt mij niet wijs dat je dan een performant en doorzichtig stukje code hebt. Bovendien zijn beide bronnen die je aanhaalt

1. kleiner dan dit forum; ik tel een paar tientallen duizenden topics en messages, GoT heeft ruim 31 miljoen berichten in ruim 1,3 miljoen topics.
2. Oracle-gerelateerd. Je had eerder in dit topic een generalisering voor Java-developers; ik heb er eentje voor Oracle-developers, velen zitten vast in hun tunnelvisie die hen zegt dat de database almachtig is.

Sommige dingen moet je gewoon niet in de database willen doen. Het is tijd dat de dikke database op diëet gaat; de ideeën die je hier hebt lopen verkondigen houden geen stand bij zo'n beetje iedere developer die hier gereageerd heeft, dat moet toch wel iets zeggen?

Je gaat er bovendien niet op in dat we zeggen dat je je business logic verwart met constraints. Als je daar het verschil blijkbaar niet tussen weet is deze discussie zinloos.

[mphilipp]

Gomez12 schreef op zaterdag 08 november 2008 @ 14:49:
[...]
Als je het alleen over primaire business logic hebt valt dit waarschijnlijk prima te doen. Alleen creer je er dan een codepunt bij ( je krijgt dan dbase - pl/sql - app - viewdingen ).

Klopt, maar dat vind ik niet zo'n punt. We hebben het niet meer over apps die je op een bierviltje of servetje uit kunt tekenen. De boel zit dat waarschijnlijk toch wel ergens in een repository en is dus inzichtelijk genoeg denk ik.

Maar ik vind bijv de afhandeling van missende gegevens ( is het 0, null of een gemiddelde van de dichstbijzijnde waardes ) wel business logica wat waarschijnlijk onderdeel is van de viewlogica. ( het is alleen boeiend tijdens het viewen, maar hoe je het behandelt is wel een vaste regel )

Uiteraard kan daarover weer oeverloos over gediscussiëerd worden, maar ik ben het met je eens. Ik vind dat ook iets dat prima in de app kan (of viewlaag als je het zo wilt noemen). Zo zijn er meer dingen te noemen die logisch gezien meer bij de app horen dan in de db.

Je moet met deze dingen een beetje pragmatisch omgaan. Dogma's hebben weinig nut. Ooit een keer een oeverloze discussie met een vogel gehad die erop stond dat er geen enkel afgeleid gegeven die database in mocht. Tuurlijk, volgens de regelen der kunst is dat verboden, maar (in die tijd was alles nog een beetje langzamer, mind you) een bepaald afgeleid gegeven redundant opnemen in een tabel was gewoon veel sneller dan 'm steeds weer gaan ophalen. Maar meneer was fundamentalist (had zelfs een baardje) en wilde er niets van weten. Typisch voorbeeld van een papieren database specialist. Soms is het gewoon handiger om het eens niet volgens de regeltjes te doen. Als je daar een goede reden voor hebt is daar niets mis mee. Zolang je het als ontwerpbeslissing opneemt in je docco is er niets aan de hand.

[mphilipp]

-NMe- schreef op zaterdag 08 november 2008 @ 16:44:
[...]
ik heb er eentje voor Oracle-developers, velen zitten vast in hun tunnelvisie die hen zegt dat de database almachtig is.

Kunnen 'we' daar nu eindelijk eens mee ophouden voordat ik een klacht ga indienen bij de commissie voor gelijke behandeling? Ik verwacht iets meer verstand van een admin aub.

[ Voor 3% gewijzigd door mphilipp op 08-11-2008 16:50 ]

[NMe]

mphilipp schreef op zaterdag 08 november 2008 @ 16:50:
[...]

Kunnen 'we' daar nu eindelijk eens mee ophouden voordat ik een klacht ga indienen bij de commissie voor gelijke behandeling? Ik verwacht iets meer verstand van een admin aub.

1. Ik heb het over velen, niet over iedereen.
2. Ik zie Gabberhead die instelling al in dit hele topic tentoonsprijden en selectief op die dingen reageren waar hij een database-draai aan kan geven.
3. Ik beledig niemand, ik doe een constatering. Doe ermee wat je wil.
4. Waarom moet mijn adminfunctie er nu weer bij gehaald worden?

[Gomez12]

mphilipp schreef op zaterdag 08 november 2008 @ 16:48:
[...]

Klopt, maar dat vind ik niet zo'n punt. We hebben het niet meer over apps die je op een bierviltje of servetje uit kunt tekenen. De boel zit dat waarschijnlijk toch wel ergens in een repository en is dus inzichtelijk genoeg denk ik.

En daar zit denk ik het misverstand.
Het originele topic ging over een cms en hoe om te gaan met postcodes, imho in 99% van de gevallen goed uit te tekenen op een bierviltje.
Dat het in enterprise apps handig kan zijn om dit soort dingen te doen is leuk en aardig. Maar Gabberhead ging deze enterprise regels even voorstellen als best practices voor alle dbase toepassingen, en dat is gewoon niet toe te passen.

Laat ik het dan herformuleren :
Logica in je dbase is ( misschien ) handig als je :
A : Enkel Oracle of MSSQL gebruikt en weet nooit te hoeven switchen
B : Je de mensen / kennis / geld hebt om er even een extra code laag tussen te zetten en deze te beheersen
C : Je de business rules zo primair kan opstellen dat het ook echt nut heeft.

Voornamelijk B zorgt ervoor dat het voor ongeveer 99% van de dbase driven apps niet handig is.

[...]
Uiteraard kan daarover weer oeverloos over gediscussiëerd worden, maar ik ben het met je eens. Ik vind dat ook iets dat prima in de app kan (of viewlaag als je het zo wilt noemen). Zo zijn er meer dingen te noemen die logisch gezien meer bij de app horen dan in de db.

En dan kom je dus weer terecht bij versplintering van je code. Wat niet erg is als je aparte teams hebt die volgens duidelijke afspraken hun ding doen, waardoor het niet versplinterd maar gewoon duidelijk gescheiden wordt.
Maar wel een ramp voor "simpele" programmeurs die alletwee moeten beheersen en controleren...

Ooit een keer een oeverloze discussie met een vogel gehad die erop stond dat er geen enkel afgeleid gegeven die database in mocht. Tuurlijk, volgens de regelen der kunst is dat verboden,

Tsja, met dat soort mensen altijd snel uitgesproken...

Als het een requirement is dat er een omzetgrafiek te tonen is van de laatste 10 jaar dan ga ik echt niet vanuit elke verkoopregel de omzet per artikel ophalen... Dan gaan er echt wel afgeleide gegevens inkomen...

[Anoniem: 259970]

Ik krijg sterk het idee dat er veel verwarring is over de definitie van Business Logica en dat is niet zo vreemd.
Volgens mij zijn er twee grote dingen die deel uitmaken van Business Logica:
- Regels/Constraints
- Workflow

Veel regels kunnen in de database worden gecontroleerd; een order mag bijvoorbeeld niet geplaatst worden, wanneer een oude order nog niet betaald is.

Voor de workflow geld echter wat anders. Als een order geplaatst is moet er een mail worden verstuurd, of moet er een bestand worden klaargezet.

Business Logica is gewoon een te abstract begrip: een deel kan in de database worden opgelost, maar een ander deel kan het allerbest in de applicatie (liefst aparte laag) worden opgelost.

[mphilipp]

Gomez12 schreef op zaterdag 08 november 2008 @ 18:01:
[...]
En daar zit denk ik het misverstand.
Het originele topic ging over een cms en hoe om te gaan met postcodes, imho in 99% van de gevallen goed uit te tekenen op een bierviltje.
Dat het in enterprise apps handig kan zijn om dit soort dingen te doen is leuk en aardig. Maar Gabberhead ging deze enterprise regels even voorstellen als best practices voor alle dbase toepassingen, en dat is gewoon niet toe te passen.

Dat is het door mij zo verfoeide dogmatisch denken. Hoewel het op zich nooit kwaad kan om iets (hoe klein dan ook) zo goed mogelijk op te zetten. Je moet het echter niet overdrijven. btw: er zijn wel hele grote Enterprise-CMS pakketten, maar daar ging het hier ook niet over denk ik

Laat ik het dan herformuleren :
Logica in je dbase is ( misschien ) handig als je :
A : Enkel Oracle of MSSQL gebruikt en weet nooit te hoeven switchen
B : Je de mensen / kennis / geld hebt om er even een extra code laag tussen te zetten en deze te beheersen
C : Je de business rules zo primair kan opstellen dat het ook echt nut heeft.
Voornamelijk B zorgt ervoor dat het voor ongeveer 99% van de dbase driven apps niet handig is.

Hoe kom je aan die 99% vraag ik me af? Je wou toch niet beweren dat al die Oracle/MS SQL specialisten de afgelopen decennia aan slechts 1% van de applicaties hebben gewerkt? Want daar komt het zo'n beetje op neer wat je zegt. Bedrijven zitten helemaal niet te wachten om te switchen. Vaak maakt men een strategische keuze voor de een of de ander en er is als je naar de markt kijkt tegenwoordig ook weinig anders te krijgen wat nog een beetje in de buurt komt. Net als de keuze voor je OS. Sommige bedrijven zetten in op Windows en die kopen dan MS SQL (alleen sukkels draaien Oracle op Windows ), anderen kopen Oracle. In principe kun je dan nog van OS switchen, maar dat doe je niet zomaar. Noem mij een bedrijf die voor zijn lol zomaar even een andere database of boekhoudpakket implementeert.
Ik vind dus het argument dat je dan 'vast' zou zitten aan één database een leuke, maar weinig steekhoudende. Als iemand een maatwerkapp laat maken, heeft ie waarschijnlijk ook wel nagedacht over onderhoud. Ik heb dat zelf jaren lang gedaan voor Oracle (onderhoud aan maatwerkspul). Bedrijven die dat leuk vinden, hebben zelf ontwikkelaars in dienst om de boel te onderhouden.
En C lijkt me niet zo'n groot probleem. Het is wél de bedoeling dat je over die dingen nadenkt, dus als je dan niet in staat bent om fatsoenlijke br te definiëren, klopt er iets niet.

MySQL heeft volgens mij tegenwoordig ook constraints en stored procedures. Als ik dan een app zou maken, zou ik net zo makkelijk wat rotzooi in de db stoppen. Tenzij ik iets maak dat op meerdere platformen moet kunnen draaien. Maar dan zijn we weer bij af: denk na voordat je begint en maak je keuzes op een verstandige manier. Motiveer waarom je die keuze maakt en valideer dat tegenover je eigen ontwerpeisen. Is een van je ontwerpeisen, en je wilt tóch logica in de db, moet je je realiseren wat dat betekent.

[mphilipp]

-NMe- schreef op zaterdag 08 november 2008 @ 17:03:
[...]

1. Ik heb het over velen, niet over iedereen.
2. Ik zie Gabberhead die instelling al in dit hele topic tentoonsprijden en selectief op die dingen reageren waar hij een database-draai aan kan geven.
3. Ik beledig niemand, ik doe een constatering. Doe ermee wat je wil.
4. Waarom moet mijn adminfunctie er nu weer bij gehaald worden?

Ik had het over 'we'. Er vlogen al een tijdje steeds weer zeer overbodige opmerkingen in het rond over 'dat Oracle volk'. Een beetje puberaal nivo zullen we maar zeggen. En een admin heeft daar in zoverre mee te maken dat je van zo iemand mag verwachten dat ie zich niet verlaagd tot het nivo van de gemiddelde puber en nadenkt voordat ie iets post.

Het is niet direct beledigend - ik trek het me niet persoonlijk aan - maar ik vind het onnodig. Als ik hier alleen al M$ schrijf, wordt ik op mijn vingers getikt door je collega admins/mods. See my point?

[Xiphalon]

Gabberhead schreef op zaterdag 08 november 2008 @ 11:20:
[...]


Rechten controleer je inderdaad aan de db kant. Daar waar ze vastgelegd liggen dus. Je wilt toch niet je usergegevens naar een andere laag halen om ze daar pas te controleren? Potentieel groot beveiligingslek.

Omzetten van linkjes naar tekst is geen business logica, maar een presentatiewens. En dat kan op tientallen verschillende manieren geregeld worden. Ook door zoveel mogelijk in de database te regelen. Ik ken genoeg grote websites met veelbezochte forums (nog wat meer dan Tweakers) die het zo regelen (http://technet.oracle.com http://asktom.oracle.com )

Je weet dat Oracle technet en asktom gaat herdesignen omdat het huidige platform niet schaalt en niet performant genoeg is?

Kom ik op nog een (bijna non-)argument om een database alleen als dataopslag-eenheid te gebruiken: Schaalbaarheid.

Een dikke db schaalt slechter (of het kost letterlijk tonnen), dan een multi-tier applicatie, waar je rustig simpele el-cheapo applicatieservers kan bijzetten zonder dat de database het relatief echt druk krijgt.

Ik vind wel dat de database ervoor moet zorgen dat de gegevens correct en intact worden opgeslagen, en dat daar dus SP's/triggers voor zijn. Maar als die fouten geven is dat m.i. een interne fout in de applicatie, de data had in de applicatieserver al gecontroleerd moeten zijn.

[.oisyn]

mphilipp schreef op zaterdag 08 november 2008 @ 20:23:
[...]

Ik had het over 'we'. Er vlogen al een tijdje steeds weer zeer overbodige opmerkingen in het rond over 'dat Oracle volk'.

-NMe- had het over velen. Niet zonder meer iedereen die met Oracle werkt - geen generalisatie dus (aangezien niet alle Oracle mensen over een kam werden geschoren). Als je dat al niet eens meer mag zeggen dan weet ik het niet meer.

Dat "M$" wordt afgekeurd heeft een hele andere reden en is dus een drogredenering.

[Gomez12]

mphilipp schreef op zaterdag 08 november 2008 @ 20:20:
[...]
Hoe kom je aan die 99% vraag ik me af? Je wou toch niet beweren dat al die Oracle/MS SQL specialisten de afgelopen decennia aan slechts 1% van de applicaties hebben gewerkt? Want daar komt het zo'n beetje op neer wat je zegt.

Nee, idd mijn fout. Had veel en veel meer dan 99% had het moeten zijn

Bijna elk zelfgebouwd / opensource / hobby cms is al niet gebaseerd op oracle / ms sql. Bijna elk hobbybob dbase driven programma gebruikt geen oracle / ms sql. Denk aan interne acces databases etc.

En die hobbybob progjes / opensource progjes overschaduwen al die specialisten gigantisch in aantal ( over kwaliteit doe ik om de een of andere reden geen uitspraak )

Zo kom ik op veel meer dan 99%...

[Gabberhead]

Ik heb zo'n beetje alles dit onderwerp wel gezegd wat ik wil zeggen. Sommige mensen zijn het met me eens, sommigen niet.

In deze post wil ik wat laatste open eindjes afsluiten met een reactie van mijn kant en dan denk ik dat ik er wel klaar mee ben.

@-NMe-: De reden dat ik niet op alle reacties heb gereageerd heeft er niks mee te maken dat ik alleen in mijn eigen straatje wil spreken, alleen maar met het praktische feit dat ik in dit topic van tig kanten wordt toegesproken en ik gewoon de tijd niet heb om op iedereen te reageren. Dus heb ik meestal alleen de meest duidelijke voorbeelden van mijn punt aangehaald.

@darkmage: het redesign van asktom, technet (en metalink) is al enkele maanden geleden voltooid. Deze sites draaien nu allemaal op Apex, met vrijwel alle functionaliteit in de database, juist omdat dat veel schaalbaarder is.

[Janoz]

Apex is, net als OC4J waarop oa Forms draait, een applicatie server en geen database server. In principe heb je dan gewoon te maken met een businesslogic laag.

[mphilipp]

.oisyn schreef op zaterdag 08 november 2008 @ 22:27:
[...]
-NMe- had het over velen. Niet zonder meer iedereen die met Oracle werkt - geen generalisatie dus (aangezien niet alle Oracle mensen over een kam werden geschoren). Als je dat al niet eens meer mag zeggen dan weet ik het niet meer.

Dat "M$" wordt afgekeurd heeft een hele andere reden en is dus een drogredenering.

Het is goed. Tegen zulke argumenten is niets in te brengen. Als je iets niet wilt snappen, kan ik daar ook niets aan doen.

[.oisyn]

Ik kan natuurlijk precies diezelfde opmerking nu gaan herhalen tegen jou, maar ik ben niet zo kinderachtig dus laten we het hier maar bij laten

[ Voor 97% gewijzigd door .oisyn op 10-11-2008 12:54 ]

[pedorus]

Toch he,

mphilipp schreef op zaterdag 08 november 2008 @ 13:45:
Maar je doet of ik heel dogmatisch eis dat alles in die db zit. Dat is niet zo. Ik wil wel graag een bepaald minimum in die database hebben, en dan gaat het om zaken die met de correctheid van de data te maken hebben. Ik heb gewoon teveel ellende gezien doordat men als een kip zonder kop nieuwe programma's aan het systeem toevoegde (of ergens anders in de organisatie die op dezelfde data werkte) of zaken veranderde, zonder rekening te houden met de bestaande situatie. Allemaal heel dom en zo hoort het niet, maar feit is dat het gewoon gebeurt. Ik wil dus graag dat het systeem netjes blijft.

Laten we zeggen dat ik iets te vaak systemen ben tegen gekomen waar men hele pakken controlelijstjes en rapportjes had om te checken of alles nog kosjer was. Dat is iets dat ik pertinent weiger te maken natuurlijk.

Ligt het nou aan mij, of klinkt hier tussen de regels toch iets door dat Oracle-mensen hun zaakjes wel goed voor elkaar hebben, en de rest er vaak een zootje van maakt?
De eerder aangehaalde Toon Koppelaars heeft zelfs dit kopje in de 'Lessons learned' van zijn 'award winning' oracle paper:

Do Not Trust Java Geeks

Het is vast zo dat als je dure Oracle consultants inschakelt dat je dan betere integriteit krijgt dan wanneer je goedkope Indiaanse Javakloppers inschakelt. Om daarom maar een 'dikke database' te gaan maken is me toch een brug te ver. Data-integriteit is geen doel op zich.

[dusty]

pedorus schreef op maandag 10 november 2008 @ 13:29:
[...]
Data-integriteit is geen doel op zich.

Dat ligt toch echt aan het systeem of het wel of niet een doel is. Ik kan mij systemen voorstellen waarbij Data-integriteit toch wel erg belangrijk kan zijn.

Zoals darkmage en anderen hiervoor al een keertje hebben aangehaald; De database kan prima integriteit bewaken, maar het hoort wel de laaste lijn van defensie te zijn, niet de eerste en/of de enige.

[Gomez12]

pedorus schreef op maandag 10 november 2008 @ 13:29:
Data-integriteit is geen doel op zich.

Doe eens een paar conversies voor grotere mkb bedrijven en ik gok dat je hierop terug gaat komen.
Ik heb in de loop der jaren redelijk wat van dit soort conversies gedaan en dan wil je echt niet weten hoeveel bagger er in de dbase staat wat meestal gered / genegeerd wordt door de app ( en soms ook door gewoon adviezen te geven als : bij dit statistieken programma moet je alleen deze opties gebruiken, gebruik je de rest dan krijg je andere resultaten ( omdat dan de bagger in de dbase meegenomen wordt ) )

Een dbase is geen excel bestand waar je even wat in knipt en plakt, over het algemeen staat er voor jaren data in. Elke inconsequentie betekent ongelovelijk veel uitzoekwerk ( want over het algemeen zijn die fouten niet gisteren in de dbase gekomen ) en als je het gevonden hebt dan is het maar net de vraag waar je het wilt gaan oplossen ( was het een fout die half doorwerkte in de jaarcijfers en daarom een 100% correcte correctie boeking heeft gekregen dan kan je hem niet negeren, maar moet je hem half correct maken )

Het eindpunt van een zaak is imho toch bijna altijd de data. Klopt deze niet, dan heb je altijd weer een uitdaging.

Ik heb al verschillende patches ( van verschillende leveranciers ) gezien die de hoofd-app updaten en de dbase correct maken. Dat is leuk, maar alle secundair afhankelijke programma's die een fix bevatten mag je ook weer gaan updaten....

[pedorus]

dusty schreef op maandag 10 november 2008 @ 18:43:
Dat ligt toch echt aan het systeem of het wel of niet een doel is. Ik kan mij systemen voorstellen waarbij Data-integriteit toch wel erg belangrijk kan zijn.

Het was een beetje een woordgrapje om het "geen doel op zich" te noemen Ik bedoelde meer dat inconsequente data ongewenst is, maar dat je je wel af moet vragen of de kosten van integere data niet te hoog worden. In bijna iedere bedrijfsdatabase zit wel wat troep, en die bedrijven doen het evengoed prima. Een 'dikke database' is iig een nogal overtrokken reactie op dit 'probleem', en het 'probleem' wordt ook nog eens niet met zekerheid opgelost.

Aan de andere kant is data-integriteit voor bepaalde systemen zeker erg belangrijk. Voor je het weet vind de accountant het anders niet meer goed

Gomez12 schreef op maandag 10 november 2008 @ 20:11:
Doe eens een paar conversies voor grotere mkb bedrijven en ik gok dat je hierop terug gaat komen.

Been there, done that. Het leukste is het ook bijvoorbeeld als het tekstveld waar je naartoe wil converteren onvoldoende lengte heeft. Of om alle data weer georganiseerd uit een misbruikt memo-veld te krijgen

Het eindpunt van een zaak is imho toch bijna altijd de data. Klopt deze niet, dan heb je altijd weer een uitdaging.

Inderdaad. En dat is niet erg, want dat zorgt dan weer voor werk. Het is volgens mij een illusie om te denken dat dit soort problemen echt worden opgelost, dus we kunnen er beter maar mee leren leven.

[dusty]

pedorus schreef op maandag 10 november 2008 @ 20:20:
[...]
Been there, done that. Het leukste is het ook bijvoorbeeld als het tekstveld waar je naartoe wil converteren onvoldoende lengte heeft. Of om alle data weer georganiseerd uit een misbruikt memo-veld te krijgen
[...]

Veel leuker is een "Omschrijving"-veld van artikelen, die verschillende malen in verschillende tabellen wordt opgeslagen, en dan moet je dat gaan migreren naar een nieuwe database, waarbij het natuurlijk niet duidelijk is wanneer je welke omschrijving voor een artikel moet gebruiken, omdat soms de column uit Tabel A beter lijkt, en soms die van Tabel B

[Gomez12]

pedorus schreef op maandag 10 november 2008 @ 20:20:
[...]
Been there, done that. Het leukste is het ook bijvoorbeeld als het tekstveld waar je naartoe wil converteren onvoldoende lengte heeft. Of om alle data weer georganiseerd uit een misbruikt memo-veld te krijgen

Aub niet beginnen over string manipulaties in memo-velden. Daar heb ik nog bijna nachtmerries van... Als het beperkt blijft tot een simplele 50 if-then structuren na een new-line dan ben ik gewoon blij...

[...]
Inderdaad. En dat is niet erg, want dat zorgt dan weer voor werk. Het is volgens mij een illusie om te denken dat dit soort problemen echt worden opgelost, dus we kunnen er beter maar mee leren leven.

[redelijk sarcasme]Ach daar hebben we weer de eeuwige consultant die om de hoek komt kijken. En weer even uurtjes denkt te kunnen maken[/ redelijk sarcasme off]
Simpel gegeven, als de data goed staat dan scheelt dit bij een conversie de klant gewoon geld ( dagelijks onderhoud even daargelaten ), ik gok dat behalve de consultants er vrij weinig mensen blij worden van de uren die geschreven worden vanwege slechte data...

[whoami]

mphilipp schreef op zaterdag 08 november 2008 @ 12:00:

Ik heb een heel praktisch bezwaar tegen (alle) business logic in de app. En dat is iets dat ik al zo vaak heb zien gebeuren, en wat tot zeer grote problemen leidt vwb dataintegriteit.

Business Logica & regels om de data integriteit te bewaken zijn gewoon 2 verschillende dingen.
BL is bv: hoeveel % korting mag die klant krijgen (afhankelijk van zijn status (== ook BL, de status van een klant bepalen), bv.
Of, nog een voorbeeld van business logica: in een tariferings-applicatie voor medische beroepen bepalen hoeveel de patient terugbetaald krijgt.
Dat zijn business-regels; die regels hebben gegevens nodig die uit de DB komen (en die DB moet er idd voor zorgen dat de data consistent is opgeslagen (ref. integriteit, check constraints, unique constraints), maar alles wat er 'meer' komt bij kijken hoort imho niet in de DB.

Dat ga je - vind ik - niet in een stored procedure, function of trigger gaan plaatsen.

Als je analyse een beetje kosjer is, en die wijst uit dat item x binnen bepaalde grenzen moet vallen, zou ik dat lekker in de db stoppen. Waarom moet je die ellende in elk scherm gaan bouwen die in je app voorkomt?

Helemaal mee eens, maar dat is geen businesslogica dus.
Trouwens, je business logica stop je ook niet 'achter ieder scherm'.

En nee, dat is idd niet portable, maar er zijn niet zo gek veel bedrijven die plotseling besluiten dat ze van Oracle naar SLQ Server gaan. Generieke database applicaties heb ik niet zo gek veel gezien, maar dat komt omdat ik geen onwikkelaar meer ben, en er nu eea is verandert wat SQL betreft. Voorheen was het gewoon niet mogelijk om zomaar SQL statements uit Oracle op SQL Server te draaien door de afwijkende syntax van joins, outer joins enzo. Nu is de syntax in Oracle aangepast aan de nieuwste standaard en zou het wel mogelijk moeten zijn om generieke db apps te ontwikkelen. Vroegâh moest je dan teveel consessies doen en werdt het rete-traag.

Ik zie ook niet het probleem in om verschillende dialecten te gaan ondersteunen. Daar heb je genoeg tools voor tegenwoordig, en als je deze niet wilt gebruiken, dan ga je gewoon 2 implementaties voorzien van je datalaag. Een voor Oracle & een voor SQL Server. En da's helemaal geen probleem als je je Business Logica (en nogmaals, dan heb ik het niet over FK constraints, check constraints, unique constraints, ed), maar over de dingen die ik eerder aangehaald heb) niet in de DB voorziet.