SQL Server Unit Tests

[Koffie32]

In ons 2e studiejaar zijn wij bij de course Database Implementatie in aanraking gekomen met tSQLt, een database framework voor het unit testen van SQL code. Nu lees ik net in de MS docs dat er nog andere mogelijkheden zijn voor het unit testen van SQL code.

Nu ben ik benieuwd hoe het er in de praktijk voor staat met het unit testen van SQL code. Mijn beperkte ervaring met software-ontwikkeling doet mij vermoeden dat het in de praktijk mogelijk ondergesneeuwd is maar dat kan een vooroordeel zijn.

[Kalentum]

Bij mij op het werk wordt het niet gedaan. De unit tests gebruiken een eigen MySQL instance. We gebruiken geen stored procedures of user defined functions. En de queries die wat complexer zijn worden ook op applicatieniveau getest.

[Koffie32]

Kalentum schreef op zaterdag 22 augustus 2020 @ 10:06:
Bij mij op het werk wordt het niet gedaan. De unit tests gebruiken een eigen MySQL instance. We gebruiken geen stored procedures of user defined functions. En de queries die wat complexer zijn worden ook op applicatieniveau getest.

Met een eigen MySQL instance bedoel je een testdatabase die vooraf met een bekende populatie gepopuleerd is?

Hoe testen jullie constraints dan (checks met name), ook op applicatieniveau?

[Matis]

Tja, de vraag is altijd: Wat wil je met de testen bereiken?

M.i. hoef je de functionaliteit van SQL niet te testen, dat hebben (als het goed is), anderen al gedaan. Wij hebben voor onze databases ook memory-implementaties die (min of meer) het gedrag van MySQL reproduceren.

In het geval van Unit Testen praat je dan tegen een memory-implementatie van de database aan, met exact dezelfde interface als de "echte" database.

Je zou ook de response van MySQL kunnen mocken om de data terug te geven in hetzelfde formaat als MySQL dat zou doen.

Nogmaals, zoals @Kalentum al aangeeft, in het geval van Unit Testen zou je eigenlijk niet een (My)SQL instantie hoeven te hebben. Die komen pas op zijn vroegst bij Integratie / Systeem testen om de hoek kijken.

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 10:16:
Nogmaals, zoals @Kalentum al aangeeft, in het geval van Unit Testen zou je eigenlijk niet een (My)SQL instantie hoeven te hebben. Die komen pas op zijn vroegst bij Integratie / Systeem testen om de hoek kijken.

Gaat het nu misschien te veel richting webapplicaties? Op het moment dat je de database pas aanpakt bij je integratietests of e2e tests dan loop je het risico dat mensen beperkingen in de applicatie gaan implementeren die op databaseniveau thuis horen en ga je voorbij aan een single-point-of-definition. Mocht er later nog een andere applicatie op de database komen te draaien dan is het mogelijk dat hier een beperking vergeten wordt te impementeren.

[Matis]

Ik zie niet in hoe een database voor webapplicaties zich anders zou gedragen dan een database voor desktop applicaties
Laat staan de manier om ze te testen.

Daarbij, de database in je testomgeving is toch ook niet representatief voor een live-omgeving? Niet qua opzet en niet qua data.

Een unit test zou het allerkleinste bouwblokje van je applicatie moeten testen. In het geval van de database zou dat het omzetten van database-data naar een model zoals je die in je applicatie gebruikt.

Ik zie (nogmaals) niet in waarom je daar allereerst een echte (draaiende) database voor nodig hebt en ten tweede zie ik geen verschil in die testen of het om een webapplicatie gaat of om een desktopapplicatie.

Als het goed is, ligt er een ontwerp / contract hoe de database er uit komt te zien, welke tabellen en welke relaties er zijn. En ik zie ook niet in hoe de unit testen daarop van invloed zijn.

Misschien hebben wij een andere definitie van Unit Test.

[ Voor 73% gewijzigd door Matis op 22-08-2020 10:39 ]

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 10:34:
Ik zie niet in hoe een database voor webapplicaties zich anders zou gedragen dan een database voor desktop applicaties
Laat staan de manier om ze te testen.

Ik dacht dat het er meer in zal liggen dat je bij webapplicaties (aanname alert) vaak de situatie hebt dat er maar één applicatie op draait.

Laat ik anders de volgende situatie schetsen:

Er bestaat een relationale database waarin voor een kolom controle moet plaatsvinden of de ingevoerde datum minimaal 2 weken in de toekomst ligt vanaf het moment dat de rij wordt toegevoegd aan de dataset. Dit zou je normaal afvangen in de DDL met een check constraint op de betreffende kolom.

Nu gaan we de database pas testen op het moment dat we een e2e test uitvoeren. Ik weet nu niet waar de constraint is geïmplementeerd, in de database of in de applicatie? In het beste geval mag ik er van uit gaan dat het developmentteam weet dat dit op databaseniveau moet maar you never know....

Nu blijkt dat de constraint kennelijk in de applicatie is afgedwongen. Doordat ik een e2e test uitvoer kom ik hier nooit achter. Mijn insert met foute informatie wordt immers netjes geblokkeerd. Na 5-6 jaar wordt er besloten dat er nog een andere applicatie op de database moet worden aangesloten. Door een gebrekkige documentatie of verkeerde aanname wordt deze contraint vergeten in de nieuwe applicatie.

Uiteraard is het ook mogelijke dat twee developers de constraint anders implementeren in beide systemen waardoor in het ergste geval de constraint niet hetzelfde functioneert. Ook dat is een risico dat wordt genomen.

[Matis]

Dit is m.i. niet het doel/taak van een Unit Test. Die moet gewoon rij uit de tabel halen (of dat die wel of niet 2 weken oud is boeit helemaal niets) en daar een net Model van maken zoals de applicatie hem verwacht.

Een andere Unit Test zou moeten testen of je een rij welke twee weken oud is wel of niet in een (fictieve) database kunt inserten. Maar als die test op applicatie niveau ligt, hoeft er eigenlijk helemaal geen database aan te pas te komen.

Je hoeft dan alleen te controleren of er uberhaupt een call wordt gedaan naar de (fictieve) database. Is dat wat je verwacht, dan slaagt de test. Zo niet, klopt de applicatie niet en zul je de code moeten aanpassen.

Pas bij het (op zijn vroegst) integratietesten zul je de twee "units" samenvoegen en kun je de werking van de hele "pijplijn" testen. Of je dit tegen een draaiende instantie van MySQL wilt doen of tegen een fictieve database kan ik niet beoordelen. Maar in ons geval proberen we dat zo min mogelijk te doen.

Pas bij systeem- en acceptatietesten komen er echte databases om de hoek kijken.

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 10:51:
Een andere Unit Test zou moeten testen of je een rij welke twee weken oud is wel of niet in een (fictieve) database kunt inserten. Maar als die test op applicatie niveau ligt, hoeft er eigenlijk helemaal geen database aan te pas te komen.

Dit wijst toch op een slecht ontwerp lijkt mij als die controle in de applicatie plaatsvindt. Het punt is dat jij geen controle hebt over waar de constraint is geïmplementeerd op het moment dat je het niet op de database unit test kan het zijn dat iemand dit in de applicatie afvangt. Je unit integratietest zegt dan "Jups, gaat goed ik vang dit af", maar dit introduceert mogelijke onderhouds/uitbreidingsproblemen in de toekomst.

• Meerdere applicaties die de database gebruiken, is meerdere plekken waar je je constraint moet aanpassen.
• Meerdere applicaties die de database gebruiken, en de kans bestaat dat twee developers de constraint anders impementeren.
• Meerdere applicaties die de database gebruiken, bij een gebrekkige documentatie wordt mogelijk de constraint over het hoofd gezien en niet geimplementeerd als het op de applicatiezijde wordt afgedwongen.

Matis schreef op zaterdag 22 augustus 2020 @ 10:51:
Je hoeft dan alleen te controleren of er uberhaupt een call wordt gedaan naar de (fictieve) database. Is dat wat je verwacht, dan slaagt de test. Zo niet, klopt de applicatie niet en zul je de code moeten aanpassen.

Je zult ook moeten weten of een database de goede foutmeldingen teruggeeft aan de caller en constraints goed afhandelt.

[edeboeck]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:03:
[...]

Dit wijst toch op een slecht ontwerp lijkt mij als die controle in de applicatie plaatsvindt. Het punt is dat jij geen controle hebt over waar de constraint is geïmplementeerd op het moment dat je het niet op de database unit test kan het zijn dat iemand dit in de applicatie afvangt. Je unit integratietest zegt dan "Jups, gaat goed ik vang dit af", maar dit introduceert mogelijke onderhouds/uitbreidingsproblemen in de toekomst.

• Meerdere applicaties die de database gebruiken, is meerdere plekken waar je je constraint moet aanpassen.
• Meerdere applicaties die de database gebruiken, en de kans bestaat dat twee developers de constraint anders impementeren.
• Meerdere applicaties die de database gebruiken, bij een gebrekkige documentatie wordt mogelijk de constraint over het hoofd gezien en niet geimplementeerd als het op de applicatiezijde wordt afgedwongen.

[...]

Je zult ook moeten weten of een database de goede foutmeldingen teruggeeft aan de caller en constraints goed afhandelt.

Je kan het ook anders bekijken: als jouw database door 2 verschillende toepassingen gebruikt wordt, en voor die ene toepassing de constraint niet van toepassing is en voor de andere wel, wat doe je dan met jouw situatie? Enkel en alleen dit argument is al voldoende om de constraint niet op DB-level te leggen.

Ik heb het gevoel dat je het heel erg database-centered bekijkt... probeer het te shiften naar data-centered: zorg dat jouw datamodel ok is (=kan de data op een correcte manier opslaan), maar leg de verantwoordelijkheid voor het toevoegen van de correcte data bij de toepassing (het is immers quasi onmogelijk om de volledig correcte toepassing van de logica af te dwingen op DB-niveau).
Als je dan 2 toepassingen hebt die een bepaalde constraint moeten afdwingen, hoort die dan ook bij de 2 toepassingen thuis... op die manier houd je alle logica netjes samen op 1 plaats, namelijk jouw toepassing (in geval van 3-layer netjes in de domain layer).

In de praktijk ben ik het al vaak tegengekomen dat een aantal constraints die normaal in de DB geïmplementeerd worden, niet geïmplementeerd worden omdat het bij aanpassingen te veel werk vraagt... al meer dan eens een DB tegengekomen waar enkel de relaties gelegd worden (los van indexen) en verder geen constraints... die worden dan in de toepassing afgedwongen.

[Matis]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:03:
Dit wijst toch op een slecht ontwerp lijkt mij als die controle in de applicatie plaatsvindt. Het punt is dat jij geen controle hebt over waar de constraint is geïmplementeerd op het moment dat je het niet op de database unit test kan het zijn dat iemand dit in de applicatie afvangt. Je unit integratietest zegt dan "Jups, gaat goed ik vang dit af", maar dit introduceert mogelijke onderhouds/uitbreidingsproblemen in de toekomst.

Ho Ho. Ik kan allereerst niet bepalen of het een slecht ontwerp is of niet. Daarvoor ken ik jouw code niet. Ik dacht begrepen dat jouw systeem momenteel zo in elkaar zit. Daarnaast kan ik ook niet beoordelen of dit een klant(specifieke) wens is of een generieke wens/eis in het systeem.

• Meerdere applicaties die de database gebruiken, is meerdere plekken waar je je constraint moet aanpassen.
• Meerdere applicaties die de database gebruiken, en de kans bestaat dat twee developers de constraint anders impementeren.
• Meerdere applicaties die de database gebruiken, bij een gebrekkige documentatie wordt mogelijk de constraint over het hoofd gezien en niet geimplementeerd als het op de applicatiezijde wordt afgedwongen.

Je zult ook moeten weten of een database de goede foutmeldingen teruggeeft aan de caller en constraints goed afhandelt.

Maar je haalt er nu veel en veel meer dingen bij dan in je aanvankelijke vraag. Ik wil helemaal niet weten hoe jouw applicatie er uitziet.

Dit ging over twee heel eenvoudige dingen. Unit Testen en het (al dan niet) gebruik van draaiende SQL servers. Ik vind dat een Unit klein gehouden moet worden.

Je hoeft niet te testen of SQL een juiste error code teruggeeft bij een test. Je moet testen of en hoe die foutmelding in jouw systeem wordt afgevangen. Je hoeft niet te testen of SQL de juiste informatie teruggeeft op de vraag die je hem stelt. Je moet testen of de data die wordt teruggegeven juist wordt omgezet naar een Model in je applicatie.

Dát is de verantwoordelijkheid van Unit Testen. Als je de testen wilt "opblazen"

De dingen die je in bovenstaande lijst opsomt, vallen m.i. niet onder de term Unit Test, maar zitten al veel hoger in de keten.

[Matis]

edeboeck schreef op zaterdag 22 augustus 2020 @ 11:13:
Je kan het ook anders bekijken: als jouw database door 2 verschillende toepassingen gebruikt wordt, en voor die ene toepassing de constraint niet van toepassing is en voor de andere wel, wat doe je dan met jouw situatie? Enkel en alleen dit argument is al voldoende om de constraint niet op DB-level te leggen.

Ik vind het sowieso eng om applicatie-specifieke (al dan niet klantspecifiek) constraints in de database te leggen. Op het moment dat je van MSSQL naar een andere RDBMS gaat, kan zomaar die constraint niet meer mogelijk zijn. De "enige" constraints in de database horen m.i. de data(base)-specifieke constraints te zijn.

Ik heb het gevoel dat je het heel erg database-centered bekijkt... probeer het te shiften naar data-centered: zorg dat jouw datamodel ok is (=kan de data op een correcte manier opslaan), maar leg de verantwoordelijkheid voor het toevoegen van de correcte data bij de toepassing (het is immers quasi onmogelijk om de volledig correcte toepassing van de logica af te dwingen op DB-niveau).
Als je dan 2 toepassingen hebt die een bepaalde constraint moeten afdwingen, hoort die dan ook bij de 2 toepassingen thuis... op die manier houd je alle logica netjes samen op 1 plaats, namelijk jouw toepassing (in geval van 3-layer netjes in de domain layer).

Ja, een goede architectuur zou dit ook zo moeten afdwingen. Het zou, voor de databaselaag, volledig transparant moeten zijn of bepaalde data wel of niet in de database thuishoort. Op het moment dat hem een vraag wordt gesteld, schiet hij de data door naar de database en haalt de gevraagde data op en zet dat (al dan net in de applicatie-laag) om naar een Model.

In de praktijk ben ik het al vaak tegengekomen dat een aantal constraints die normaal in de DB geïmplementeerd worden, niet geïmplementeerd worden omdat het bij aanpassingen te veel werk vraagt... al meer dan eens een DB tegengekomen waar enkel de relaties gelegd worden (los van indexen) en verder geen constraints... die worden dan in de toepassing afgedwongen.

Ja, en dan loop je dus ook tegen de problemen aan dat migreren naar een ander platform / RDBMS heel lastig tot onmogelijk wordt.

[Creepy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:03:
[...]

Even heel kort door de bocht: Ben je nu je DB aan het unittesten? Of wil je controleren of de constraints die je verwacht er daadwerkelijk zijn? Het eerst moet je niet willen testen, die DB werkt wel. Als je daar al niet vanuit kan gaan dan zul je wat mij betreft ook je OS moeten gaan testen of de system calls wel doen wat ze moeten doen

Daarnaast introduceer je heel wat problemen als meerdere applicaties dezelfde data aan het muteren is. Dat zul je dan ook moeten gaan testen, maar dan zijn het al lang geen unittests meer...

En natuurlijk, als je meerdere applicaties hebt die de DB gaan muteren, dan is het denk ik het meest duidelijk om constraints e.d. in je DB vast te leggen. Maar dit wijzigen vergt dus ook dat alle applicaties die de DB kunnen muteren dan ook aangepast moeten worden. En op applicatie niveau cachen wordt ook ineens lastig, dat kan je dan weer oplossen met een centrale cache maar zou het dan niet beter zijn om maar 1 applicatie/dienst/service te hebben die de DB muteert? Dan ligt die verantwoordelijkheid ook maar op 1 plek.

En heel eerlijk: ben je nu niet heel theoretisch bezig? Heb je een praktijkvoorbeeld waarbij dit echt een issue is en waarvan je zelf overtuigd bent dat het ontwerp van dat geheel echt kloppend is?

[Koffie32]

edeboeck schreef op zaterdag 22 augustus 2020 @ 11:13:
Je kan het ook anders bekijken: als jouw database door 2 verschillende toepassingen gebruikt wordt, en voor die ene toepassing de constraint niet van toepassing is en voor de andere wel, wat doe je dan met jouw situatie? Enkel en alleen dit argument is al voldoende om de constraint niet op DB-level te leggen.

Ik kan zelf geen situatie bedenken waarin dat het geval zou zijn. Dat zou namelijk betekenen dat het geen constraint betreft op het datamodel en dus ook niet relevant is voor hoe de data wordt opgeslagen. Heb je hier een voorbeeld van?

edeboeck schreef op zaterdag 22 augustus 2020 @ 11:13:
Ik heb het gevoel dat je het heel erg database-centered bekijkt... probeer het te shiften naar data-centered: zorg dat jouw datamodel ok is (=kan de data op een correcte manier opslaan), maar leg de verantwoordelijkheid voor het toevoegen van de correcte data bij de toepassing (het is immers quasi onmogelijk om de volledig correcte toepassing van de logica af te dwingen op DB-niveau).
Als je dan 2 toepassingen hebt die een bepaalde constraint moeten afdwingen, hoort die dan ook bij de 2 toepassingen thuis... op die manier houd je alle logica netjes samen op 1 plaats, namelijk jouw toepassing (in geval van 3-layer netjes in de domain layer).

Constraints liggen juist op het datamodel en worden bij het maken van een CDM (Conceptueel Data Model) meegenomen in het ontwerp.

Welke constraint op het toevoegen/manipuleren van data is volgens jouw niet af te dwingen op databasenivea? In je voorbeeld houdt je de logica juist niet op 1 plaats maar verspreid je het over 2 plekken, de twee applicaties en ga je voorbij aan een single point of definition.

edeboeck schreef op zaterdag 22 augustus 2020 @ 11:13:
In de praktijk ben ik het al vaak tegengekomen dat een aantal constraints die normaal in de DB geïmplementeerd worden, niet geïmplementeerd worden omdat het bij aanpassingen te veel werk vraagt... al meer dan eens een DB tegengekomen waar enkel de relaties gelegd worden (los van indexen) en verder geen constraints... die worden dan in de toepassing afgedwongen.

Ik denk dat het probleem met name is dat er geen dedicated DBA is bij die bedrijven. Het bijhouden van constraints op databaseniveau is toch een stuk eenvoudiger.

Stel je hebt de situatie dat 2 verschillende bedrijven een applicatie maken op 1 database. Die bedrijven zullen niet snel hun applicatielogica delen. Hoe ga je er nu voor zorgen dat bij beide een aanpassing in de constraint goed (en op eenzelfde wijze) wordt doorgevoerd?

[Matis]

@Creepy ik krijg ook het gevoel dat het nu óf heel theoretisch is/wordt óf dat de TS nog niet het antwoord heeft gehoord waar hij graag op hoopte. En nu met allerhande (niet gerelateerde) eisen / wensen alsnog tot een antwoord/suggestie te komen welke hij graag wil horen.

[Creepy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:25:
Stel je hebt de situatie dat 2 verschillende bedrijven een applicatie maken op 1 database. Die bedrijven zullen niet snel hun applicatielogica delen. Hoe ga je er nu voor zorgen dat bij beide een aanpassing in de constraint goed (en op eenzelfde wijze) wordt doorgevoerd?

Dat moet je wat mij betreft niet willen...... problem solved?

Als dat nodig is dan ontsluit je de data met een API oid. Dan heb je niet op meerdere plekken de verantwoordelijkheid liggen voor het muteren van data. Reken er maar op dat er wat stuk gaat aan 1 van de applicaties als je in je DB een constraint aanpast of toevoegd. Met een API ervoor kan je het oude gedrag in stand houden en nieuw gedrag introduceren zodat beide applicaties in hun eigen tijd kunnen worden aangepast bijv.

[ Voor 31% gewijzigd door Creepy op 22-08-2020 11:29 ]

[Woy]

Sowieso is het altijd mijn uitgangspunt dat de database geen goede interface tussen applicaties zijn, en dus liever niet gedeeld dienen te worden. Anders zie je vaak al snel allemaal business logica in SPs verdwijnen, die over de lange termijn slecht onderhoudbaar zijn.

Liever een duidelijke gespecificeerde interface op applicatie niveau. De DB is gewoon een implementatie detail voor de storage van de applicatie.

Testen of de constraints die je daar gedefinieerd hebt ook daadwerkelijk aangemaakt zijn kun je gewoon met allerhande database tools laten doen.

Echt unit tests op DB niveau heb ik ook nog nooit gedaan.

Wel geautomatiseerde integratie testen die de data access testen.

[ Voor 24% gewijzigd door Woy op 22-08-2020 11:34 ]

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 11:17:
Maar je haalt er nu veel en veel meer dingen bij dan in je aanvankelijke vraag. Ik wil helemaal niet weten hoe jouw applicatie er uitziet.

Volgens mij blijft de vraag hetzelfde. Ik heb nooit een context geschetst die beperkingen oplegde aan een antwoord. De vraag was of het unit testen van SQL code in de praktijk plaatsvindt. De antwoorden bekijkend denk ik dat dit een ondergesneeuwd iets is. Met name de opmerking van @edeboeck verbaasd mij waarin hij/zij stelt dat "in de praktijk ben ik het al vaak tegengekomen dat een aantal constraints die normaal in de DB geïmplementeerd worden, niet geïmplementeerd worden omdat het bij aanpassingen te veel werk vraagt", dit gaat tegen alles in wat wij in onze opleiding leren.

Matis schreef op zaterdag 22 augustus 2020 @ 11:17:
Dit ging over twee heel eenvoudige dingen. Unit Testen en het (al dan niet) gebruik van draaiende SQL servers. Ik vind dat een Unit klein gehouden moet worden.

Het alleen testen van 1 constraint is klein genoeg lijkt me. Unit tests met tSQLt worden in de database rechtstreeks op de database uitgevoerd. Je test geen verbinden o.d. het is hetzelfde als het testen van Java met bijvoorbeeld Mockito.

Matis schreef op zaterdag 22 augustus 2020 @ 11:17:
Je hoeft niet te testen of SQL een juiste error code teruggeeft bij een test. Je moet testen of en hoe die foutmelding in jouw systeem wordt afgevangen. Je hoeft niet te testen of SQL de juiste informatie teruggeeft op de vraag die je hem stelt. Je moet testen of de data die wordt teruggegeven juist wordt omgezet naar een Model in je applicatie.

Dus volgens jou hoeft je niet te testen of je check die de datum controleert de juiste foutmelding teruggeeft als je foute data in de database stopt? Je wil je constraint voor een single point of definition zo laag mogelijk in de keten vastleggen, en dat is in de database lijkt me.

Matis schreef op zaterdag 22 augustus 2020 @ 11:17:
De dingen die je in bovenstaande lijst opsomt, vallen m.i. niet onder de term Unit Test, maar zitten al veel hoger in de keten.

Wat valt volgens jou niet onder unit testen dan? Een check contraint op een tabel verifiëren zit volgen jou hoger in de keten?

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 11:26:
@Creepy ik krijg ook het gevoel dat het nu óf heel theoretisch is/wordt óf dat de TS nog niet het antwoord heeft gehoord waar hij graag op hoopte. En nu met allerhande (niet gerelateerde) eisen / wensen alsnog tot een antwoord/suggestie te komen welke hij graag wil horen.

Nee hoor. Ik wil een indruk krijgen over hoe in het bedrijfsleven gewerkt wordt en dan het liefst binnen verschillende sectoren. Vandaar dat ik situatieschetsen geef om te kijken waar het dan uitkomt.

[Creepy]

Ik kan je vertellen dat Woy, Matis en ik in verschillende sectoren werken. Doe er je voordeel mee

[Woy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:34:
[...]
Wat valt volgens jou niet onder unit testen dan? Een check contraint op een tabel verifiëren zit volgen jou hoger in de keten?

Wat wil je daaraan unit testen? Of de constraints ok echt werken? Dat lijkt mij standaard functionaliteit van de DB, dus niet een unit van jouw applicatie.

Of de constraints bestaan? Dat is weer afhankelijk van hoe je de DB aanmaakt, maar meestal zal dat weer gegenereerd zijn aan de hand van een definitie, dus ook niet iets wat je gaat unit testen.

[Matis]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:34:
Wat valt volgens jou niet onder unit testen dan? Een check contraint op een tabel verifiëren zit volgen jou hoger in de keten?

Nee, deze zit juist lager in de keten.
Dit valt m.i. niet onder een Unit Test waar jij je druk over hoeft te maken. Je kunt er op vertrouwen dat SQL jou een foutmelding geeft als je foutieve data in de tabel probeert te schrijven.
De taak aan jou is om een test te schrijven die zo'n (fictieve) foutmelding afvangt en het logt/rethrowed/etc etc.

Verder sluit ik me aan bij de twee heren boven me

[ Voor 4% gewijzigd door Matis op 22-08-2020 11:39 ]

[Kalentum]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:25:

Stel je hebt de situatie dat 2 verschillende bedrijven een applicatie maken op 1 database. Die bedrijven zullen niet snel hun applicatielogica delen. Hoe ga je er nu voor zorgen dat bij beide een aanpassing in de constraint goed (en op eenzelfde wijze) wordt doorgevoerd?

Het zou kunnen maar in de praktijk ga je zo'n database dan abstraheren achter een API

Overigens ben ik ook van mening dat je database moet afdwingen dat je database data consistent is en de meest logische plek is dan de RDMS. Ik zat bij de oorspronkelijke vraag van @Koffie32 ook meer te denken in de richting van stored procedures enzo.

Maar dan de praktijk.

Ik heb het geluk te werken bij een bedrijf dat per applicatie (Microservices) 1 database heeft. Door de hoeveelheid traffic hebben we duizenden transacties per seconde, de meeste reads gelukkig. Maar dat heeft er wel voor gezorgd dat we zeer terughoudend zijn met database constraints omdat die hoe dan ook niet gratis zijn. Dus behoudens enkele kritische processen die financieel van aard zijn gebruiken we weinig of geen database constraints.

Het kan dan zeer zinvol zijn om de data constraints expres niet in je database te hebben omdat je er daar vaak maar 1 'master' van hebt. Onder bepaalde load karakteristieken (bv hoge write load die drie of vier constraints raken) kan dat killing zijn voor de beschikbaarheid van het systeem.
We kunnen dus geautomatiseerd een hoge load opvangen door applicaties bij te schalen maar we kunnen niet zomaar 3 database servers voor de writes in de lucht schoppen.

De prijs is dat een klein deel van de data niet zo consistent is als je zou willen.

[Koffie32]

Creepy schreef op zaterdag 22 augustus 2020 @ 11:23:
Even heel kort door de bocht: Ben je nu je DB aan het unittesten? Of wil je controleren of de constraints die je verwacht er daadwerkelijk zijn? Het eerst moet je niet willen testen, die DB werkt wel. Als je daar al niet vanuit kan gaan dan zul je wat mij betreft ook je OS moeten gaan testen of de system calls wel doen wat ze moeten doen

Ik wil niet maar vraag me af of het in de praktijk wordt toegepast. Het lijkt er voor nu op dat in de praktijk de database amper wordt getest. Ik weet dat databases unit testen nogal nieuw is maar ik krijg ook een beetje een indruk dat mensen er helemaal niet bekend mee zijn.

Je test beperkingen, functies en/of procedures met unit tests binnen een database (als je tSQLt gebruikt ten minste).

Creepy schreef op zaterdag 22 augustus 2020 @ 11:23:
Daarnaast introduceer je heel wat problemen als meerdere applicaties dezelfde data aan het muteren is. Dat zul je dan ook moeten gaan testen, maar dan zijn het al lang geen unittests meer...

Concurrency wordt wel goed afgehandeld in een DB, ik ga niet de DB zelf testen.

Creepy schreef op zaterdag 22 augustus 2020 @ 11:23:
En natuurlijk, als je meerdere applicaties hebt die de DB gaan muteren, dan is het denk ik het meest duidelijk om constraints e.d. in je DB vast te leggen. Maar dit wijzigen vergt dus ook dat alle applicaties die de DB kunnen muteren dan ook aangepast moeten worden. En op applicatie niveau cachen wordt ook ineens lastig, dat kan je dan weer oplossen met een centrale cache maar zou het dan niet beter zijn om maar 1 applicatie/dienst/service te hebben die de DB muteert? Dan ligt die verantwoordelijkheid ook maar op 1 plek.

Volgens mij valt dat probleem weg als je views en procedures gebruikt of mis ik iets?

Creepy schreef op zaterdag 22 augustus 2020 @ 11:23:
En heel eerlijk: ben je nu niet heel theoretisch bezig? Heb je een praktijkvoorbeeld waarbij dit echt een issue is en waarvan je zelf overtuigd bent dat het ontwerp van dat geheel echt kloppend is?

De vraag komt zoals ik al stelde voort uit dat wij hebben geleerd unit tests te schrijven om onze databasebeperkingen te testen in de database nog voor er een applicatie bestaat. Ik vroeg mij af of dit in de praktijk ook wel gebeurd of dat het nog een te nieuw iets is of als teveel werk wordt gezien.

[Woy]

Als je daadwerkelijk gebruikt zou maken van stored procedures, of logica in triggers kan ik mij wat voorstellen van unit testen. Maar puur het opslaan van data of constraints valideren niet.

Als de DB gewoon uit een model of code gegenereerd wordt kun je die gewoon checken, en zolang niemand handmatig wijziging maakt hoort dat gewoon te matchen.

Het schema zou verder geen business logica moeten bevatten, en dus ook geen logica die getest dient te worden, anders ben je gewoon op twee verschillende manieren je schema aan het vastleggen, en dat wordt een hel om te onderhouden

[Koffie32]

Creepy schreef op zaterdag 22 augustus 2020 @ 11:26:
[...]

Dat moet je wat mij betreft niet willen...... problem solved?

Als dat nodig is dan ontsluit je de data met een API oid. Dan heb je niet op meerdere plekken de verantwoordelijkheid liggen voor het muteren van data. Reken er maar op dat er wat stuk gaat aan 1 van de applicaties als je in je DB een constraint aanpast of toevoegd. Met een API ervoor kan je het oude gedrag in stand houden en nieuw gedrag introduceren zodat beide applicaties in hun eigen tijd kunnen worden aangepast bijv.

Views en procedures kunnen de rol van een API overnemen lijkt me.

[Koffie32]

[b]Woy in "SQL Server Unit Tests"
Echt unit tests op DB niveau heb ik ook nog nooit gedaan.

Ik denk dat dit met name het antwoord is. Ik vermoed dat het nog een te nieuw concept is.

Ik hou de reacties bijna niet meer bij.

[Koffie32]

Woy schreef op zaterdag 22 augustus 2020 @ 11:38:
[...]

Wat wil je daaraan unit testen? Of de constraints ok echt werken? Dat lijkt mij standaard functionaliteit van de DB, dus niet een unit van jouw applicatie.

Of de constraints bestaan? Dat is weer afhankelijk van hoe je de DB aanmaakt, maar meestal zal dat weer gearomatiseerd zijn aan de hand van een definitie, dus ook niet iets wat je gaat unit testen.

Met name of je implementatie goed is. Zeker bij complexe constraints die een functie aanroepen kun je net als bij softwaredevelopment fouten maken.

[Matis]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:47:
Met name of je implementatie goed is. Zeker bij complexe constraints die een functie aanroepen kun je net als bij softwaredevelopment fouten maken.

Als je dat wilt testen, is het al lang geen Unit Test meer. Maar een Integratie of Systeem test. En dat is zeker iets dat je moet testen. Of het wordt een test welke je óp de SQL-server moet draaien. Al heb ik daar geen ervaring mee.

Is dit je originele vraag welke je in de TS probeerde te stellen?

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 11:38:
[...]

Nee, deze zit juist lager in de keten.
Dit valt m.i. niet onder een Unit Test waar jij je druk over hoeft te maken. Je kunt er op vertrouwen dat SQL jou een foutmelding geeft als je foutieve data in de tabel probeert te schrijven.
De taak aan jou is om een test te schrijven die zo'n (fictieve) foutmelding afvangt en het logt/rethrowed/etc etc.

Verder sluit ik me aan bij de twee heren boven me

Als software- of webdeveloper wel maar als DBA of database-architect heb je weinig van doen met het maken van applicaties bovenop de database.

Moet wel zeggen dat dit topic mij een aardig inzicht lijkt te geven in hoe er tegen databases aan wordt gekeken. Erg leuk om te lezen maar ik krijg wel het idee dat er zéér vanuit een ik ben een developer en ik wil controle perspectief wordt gekeken.

[Koffie32]

Kalentum schreef op zaterdag 22 augustus 2020 @ 11:40:
Het zou kunnen maar in de praktijk ga je zo'n database dan abstraheren achter een API

Overigens ben ik ook van mening dat je database moet afdwingen dat je database data consistent is en de meest logische plek is dan de RDMS. Ik zat bij de oorspronkelijke vraag van @Koffie32 ook meer te denken in de richting van stored procedures enzo.

Maar dan de praktijk.

Ik heb het geluk te werken bij een bedrijf dat per applicatie (Microservices) 1 database heeft. Door de hoeveelheid traffic hebben we duizenden transacties per seconde, de meeste reads gelukkig. Maar dat heeft er wel voor gezorgd dat we zeer terughoudend zijn met database constraints omdat die hoe dan ook niet gratis zijn. Dus behoudens enkele kritische processen die financieel van aard zijn gebruiken we weinig of geen database constraints.

Het kan dan zeer zinvol zijn om de data constraints expres niet in je database te hebben omdat je er daar vaak maar 1 'master' van hebt. Onder bepaalde load karakteristieken (bv hoge write load die drie of vier constraints raken) kan dat killing zijn voor de beschikbaarheid van het systeem.
We kunnen dus geautomatiseerd een hoge load opvangen door applicaties bij te schalen maar we kunnen niet zomaar 3 database servers voor de writes in de lucht schoppen.

De prijs is dat een klein deel van de data niet zo consistent is als je zou willen.

Ik moet zeggen dat dit voor mij tot nu toe het meest bevredigende antwoord is. De argumentatie is ook meer dan logisch dat je het laat afhangen van de kosten/baten.

Inderdaad zat de vraag meer in de richting van stored procedures, checks en user defnined functions. Ik denk dat de frameworks voor het in isolatie testen van databases nog iets te onbekend zijn of irrelevant als je geen gebruik maakt van het genoemde.

[Koffie32]

Woy schreef op zaterdag 22 augustus 2020 @ 11:43:
Als je daadwerkelijk gebruikt zou maken van stored procedures, of logica in triggers kan ik mij wat voorstellen van unit testen. Maar puur het opslaan van data of constraints valideren niet.

Als de DB gewoon uit een model of code gegenereerd wordt kun je die gewoon checken, en zolang niemand handmatig wijziging maakt hoort dat gewoon te matchen.

Het schema zou verder geen business logica moeten bevatten, en dus ook geen logica die getest dient te worden, anders ben je gewoon op twee verschillende manieren je schema aan het vastleggen, en dat wordt een hel om te onderhouden

Waarom neem je de constraints dan nogmaals op in je softwaremodel? Aannemelijk is toch dat het datamodel al eerder bestaat?

[Koffie32]

Matis schreef op zaterdag 22 augustus 2020 @ 11:50:
[...]

Als je dat wilt testen, is het al lang geen Unit Test meer. Maar een Integratie of Systeem test. En dat is zeker iets dat je moet testen. Of het wordt een test welke je óp de SQL-server moet draaien. Al heb ik daar geen ervaring mee.

Is dit je originele vraag welke je in de TS probeerde te stellen?

Jups, vandaar dat ik verwees naar unit tests voor SQL Server en het tSQLt framework als voorbeeld noemde voor het uitvoeren van die tests.

Maar dit is nog steeds gewoon een unit test, je test 1 code unit, inderdaad op de server zelf, alleen waarschijnlijk niet het soort dat jij gewend bent. Het is geen integratie- of systeemtest. Je hoeft namelijk niet te integreren voor je kunt testen.

Ik ben weer bij met alle reacties.

[Goudstalen]

Moet wel zeggen dat dit topic mij een aardig inzicht lijkt te geven in hoe er tegen databases aan wordt gekeken. Erg leuk om te lezen maar ik krijg wel het idee dat er zéér vanuit een ik ben een developer en ik wil controle perspectief wordt gekeken.

Ik denk dat de meeste developers niet zo'n grote en kritieke applicaties ontwikkelen dat er een database architect bij moet komen kijken. Dan zullen ze dus zelf de databases ontwikkelen en er dus ook als een developer tegen aan kijken.

Waarom neem je de constraints dan nogmaals op in je softwaremodel? Aannemelijk is toch dat het datamodel al eerder bestaat?

Het wordt hier denk ik anders bedoeld; bij een code first approach worden constraints niet nogmaals gedefinieerd in het software model, maar juist daar gedefinieerd omdat er bij een code first approach (zie bijvoorbeeld Entity Framework) het softwaremodel het datamodel kan betreffen inclusief constraints, dat wordt in code vastgelegd en daaruit een database wordt gegenereerd.
In zo'n geval heb je eigenlijk vrijwel niets meer met de database van doen, nu kun je alle controles uitvoeren in code.

[michelvosje]

Bij een klant hadden ze in een datamigratie product meer dan honderd migratiescripts met vele statements per script. Deze scripts zijn jarenlang nooit onderdeel geweest van geautomatiseerde tests. Maar ze zijn wel in al die tijd vele malen gewijzigd.

Als experiment heb ik toen als doel gesteld om een enkel script te testen. Hierbij had ik o.a. de volgende eisen:

• Volgorde van uitvoer van tests dient geen effect te hebben op testresultaten.
• Tests moeten volledig geïsoleerd van elkaar uitgevoerd kunnen worden.
• Tests mogen geen afhankelijkheid hebben op implementatie van de scripts. Dus volledig black box.

Uiteindelijk heb ik toen een test class ontwikkeld welke als doel had om een enkel script geheel te testen. De verschillende unit tests verifieerden specifieke code paden en business rules binnenin het script. Om deze te bepalen was het script dus eigenlijk gereverse engineered.

De gebruikte technieken waren Spring Data, Hibernate, JUnit en Mockito. De schema table definitions heb ik handmatig vertaald naar Hibernate entity classes. De mechanismes van onze software voor het uitvoeren van een script functionaliteit werd verstopt achter een interface met een enkele methode run(). Deze run() methode werd uiteindelijk aangeroepen vanuit de unit tests. Voor het specifieke migratie script wat getest werd was dus een implementatie van deze interface gemaakt en een instantie hiervan werd als configuratie voor de test class gebruikt. De unit tests waren zelf verantwoordelijk voor het invoeren van test data en uitlezen van de eindresultaten m.b.v. Spring Data repositories. De eindresultaten werden vergeleken met JUnit asserts.

Ik herinner me dat het redelijk wat tijd kostte om het in te richten. Voornamelijk omdat het migratieproduct er niet op was ingericht. Ook lastig was dat normaal de databaseschema's vanuit SQL geproduceerd wordt door scripts in een specifieke volgorde uit te voeren. Dit was voor de tests verschoven naar Java m.b.v. Spring Data en Hibernate. Hierdoor werd Spring verantwoordelijk voor het beschikbaar maken van het database model voor de tests. Uiteindelijk waren er 0 referenties naar SQL / implementatie in de tests. De tests waren erg overzichtelijk. De rede voor deze technische aanpak was omdat er geen goede tools beschikbaar lijken te zijn voor PL/pgSQL.

Ik heb toen fouten in het script ontdekt door de tests. Geen idee of men er mee is verder gegaan. Een voorwaarde voor deze aanpak zou zijn dat het databasemodel gedurende het migratieproces statisch moest zijn. Het zou veel tijd kosten om de bestaande scripts daarop aan te passen. Leuk projectje om te bouwen was het wel.

[ Voor 3% gewijzigd door michelvosje op 22-08-2020 12:58 ]

[Koffie32]

michelvosje schreef op zaterdag 22 augustus 2020 @ 12:52:
Bij een klant hadden ze in een datamigratie product meer dan honderd migratiescripts met vele statements per script. Deze scripts zijn jarenlang nooit onderdeel geweest van geautomatiseerde tests. Maar ze zijn wel in al die tijd vele malen gewijzigd.

Als experiment heb ik toen als doel gesteld om een enkel script te testen. Hierbij had ik o.a. de volgende eisen:

• Volgorde van uitvoer van tests dient geen effect te hebben op testresultaten.
• Tests moeten volledig geïsoleerd van elkaar uitgevoerd kunnen worden.
• Tests mogen geen afhankelijkheid hebben op implementatie van de scripts. Dus volledig black box.

Uiteindelijk heb ik toen een test class ontwikkeld welke als doel had om een enkel script geheel te testen. De verschillende unit tests verifieerden specifieke code paden en business rules binnenin het script. Om deze te bepalen was het script dus eigenlijk gereverse engineered.

De gebruikte technieken waren Spring Data, Hibernate, JUnit en Mockito. De schema table definitions heb ik handmatig vertaald naar Hibernate entity classes. De mechanismes van onze software voor het uitvoeren van een script functionaliteit werd verstopt achter een interface met een enkele methode run(). Deze run() methode werd uiteindelijk aangeroepen vanuit de unit tests. Voor het specifieke migratie script wat getest werd was dus een implementatie van deze interface gemaakt en een instantie hiervan werd als configuratie voor de test class gebruikt. De unit tests waren zelf verantwoordelijk voor het invoeren van test data en uitlezen van de eindresultaten m.b.v. Spring Data repositories. De eindresultaten werden vergeleken met JUnit asserts.

Ik herinner me dat het redelijk wat tijd kostte om het in te richten. Voornamelijk omdat het migratieproduct er niet op was ingericht. Ook lastig was dat normaal de databaseschema's vanuit SQL geproduceerd wordt door scripts in een specifieke volgorde uit te voeren. Dit was voor de tests verschoven naar Java m.b.v. Spring Data en Hibernate. Hierdoor werd Spring verantwoordelijk voor het beschikbaar maken van het database model voor de tests. Uiteindelijk waren er 0 referenties naar SQL / implementatie in de tests. De tests waren erg overzichtelijk. De rede voor deze technische aanpak was omdat er geen goede tools beschikbaar lijken te zijn voor PL/pgSQL.

Ik heb toen fouten in het script ontdekt door de tests. Geen idee of men er mee is verder gegaan. Leuk projectje om te bouwen was het wel.

Voldoet/voldeed pgTAP niet (zelf geen ervaring met dit framework)?

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:43:
[...]

Views en procedures kunnen de rol van een API overnemen lijkt me.

Theoretisch wel. Het is alleen niet gangbaar om dat voor ook voor de buitenwereld zo te doen. Je ziet het eerder in de verschillende toepassingen op de data binnen een bedrijfscontext. Bijv. verschillende representaties van de onderliggende data voor de administratie, business-analist, data-analist.

De vraag is waar je de verantwoordelijkheid van de tests legt. Als je een database architectuur afdeling hebt die onafhankelijk van de software ontwikkelaars werken, dan kan ik me voorstellen dat je de views ook aan de database kant wil blijven valideren, zodat je niet van een ontwikkelaar hoort dat zijn unittest faalt, maar dat je dat zelf al door hebt voordat je een wijziging in het model aanbrengt.

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:46:
[...]

Ik denk dat dit met name het antwoord is. Ik vermoed dat het nog een te nieuw concept is.

Ik hou de reacties bijna niet meer bij.

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:47:
[...]

Met name of je implementatie goed is. Zeker bij complexe constraints die een functie aanroepen kun je net als bij softwaredevelopment fouten maken.

Om het moment dat je daadwerkelijk complexe SP, constraint, checks, triggers e.d. geïmplementeerd hebt, dan is het volgens mij niet anders dan software unittesten. Als jij zegt dat een postcode uit 4 cijfers en 2 letters bestaat, wat let je om een query te schrijven die specifiek 4 letters en 1 cijfer probeert in te voeren?

Vanuit data analyse schrijf ik veel complexe SQL t.b.v. data transformaties of data te her-modelleren. Om te testen of input / output goed wordt getransformeerd schrijf ik gewoon een input dataset en een output dataset. Daar laat ik de query op los en vervolgens vergelijk ik de twee. Dat is prima te scripten in elke willekeurige programmeertaal.

[The Eagle]

Wat jij nu op school leert is dat er in een database constraints en andere zaken mogelijk zijn die iets af kunnen dwingen, en je vraagt je af of dat in de praktijk gebruikt en dus getest wordt, al dan niet middels unit of ndere testen.
Welnu, waar je hier mee te maken hebt is applicatie of bedrijfslogica en hoewel dat theoretisch met constraints afgedwongen kan worden, zie je dat soort dingen eigenlijk alleen op applicatieniveau toegepast worden. Daar draait namelijk de code met de logic, en niet in de DB.
Dat wil je ook niet op de DB hebben, om verschillende redenen. Je DB is idealiter gewoon een bak met data. De enige constraints die dat ding voor een applicatie af moet dwingen zijn de keys.

Oh ja, en van meerdee applicaties in een enkele database kan ik je wel een aantal voorbeelden geven. Heck, het stikt er van. Maar begin dan eerst maar eens te beschrijven wat jij meent dat het verschil tussen een database, een DBMS, een DB instance, een schema en een pluggable DB is, en dan praten we verder

[michelvosje]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 12:58:
[...]

Voldoet/voldeed pgTAP niet (zelf geen ervaring met dit framework)?

Er waren voor mij wat redenen om hier geen gebruik van te maken:

• Je gaat niemand vinden die ervaring heeft met dit of een vergelijkbaar product.
• Binnen de toen bestaande teams waren mensen aanwezig die kennis hadden van de tools die ik heb gebruikt.
• Extra afhankelijkheid naar de gebruikte techniek van migratiescripts. In dit geval PL/pgSQL.
• Ik ben pgTAP toen tegengekomen. En nu doet het weer pijn aan mijn ogen. Het is niet leesbaar. En het zal vrijwel nergens mee integreren. En als het dat als doet alleen met half functionerende community driven hobby producten.

[Koffie32]

michelvosje schreef op zaterdag 22 augustus 2020 @ 14:20:
[...]

Er waren voor mij wat redenen om hier geen gebruik van te maken:

• Je gaat niemand vinden die ervaring heeft met dit of een vergelijkbaar product.
• Binnen de toen bestaande teams waren mensen aanwezig die kennis hadden van de tools die ik heb gebruikt.
• Extra afhankelijkheid naar de gebruikte techniek van migratiescripts. In dit geval PL/pgSQL.
• Ik ben pgTAP toen tegengekomen. En nu doet het weer pijn aan mijn ogen. Het is niet leesbaar. En het zal vrijwel nergens mee integreren. En als het dat als doet alleen met half functionerende community driven hobby producten.

Ik ken pgTAP dan niet persoonlijk maar voor MS SQL Server en Oracle zijn er vergelijkbare redelijk volwassen pakketten voor unit testing. En hier (en de rest van onze opleiding) is er een die hier wel ervaring mee heeft.

Over de leesbaarheid doe ik geen uitspraken. Voor mij ziet het er redelijk eenvoudig uit maar ik kan me voorstellen dat je als software of webdeveloper wat minder vaak dergelijke code ziet. Net zoals ik wat minder vaak Java of JavaScript zie en dus wat meer tijd nodig heb om te achterhalen wat ergens staat.

[Koffie32]

The Eagle schreef op zaterdag 22 augustus 2020 @ 13:50:
Wat jij nu op school leert is dat er in een database constraints en andere zaken mogelijk zijn die iets af kunnen dwingen, en je vraagt je af of dat in de praktijk gebruikt en dus getest wordt, al dan niet middels unit of ndere testen.
Welnu, waar je hier mee te maken hebt is applicatie of bedrijfslogica en hoewel dat theoretisch met constraints afgedwongen kan worden, zie je dat soort dingen eigenlijk alleen op applicatieniveau toegepast worden. Daar draait namelijk de code met de logic, en niet in de DB.
Dat wil je ook niet op de DB hebben, om verschillende redenen. Je DB is idealiter gewoon een bak met data. De enige constraints die dat ding voor een applicatie af moet dwingen zijn de keys.

Het is niet alleen theoretisch met constraints af te dwingen maar ook praktisch.

Als je die definitie van een database aanhoudt dan neem ik aan dat je een afkeur hebt van relatonele databases? Volgens die definitie heb je namelijk genoeg aan een documentdatabase voor welk type applicatie/software dan ook. Waarom moet je dan immers nog verwijzende of primaire sleutels hebben? Dwing dat dan ook gewoon af op applicatieniveau.

[Koffie32]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 13:21:
Theoretisch wel. Het is alleen niet gangbaar om dat voor ook voor de buitenwereld zo te doen. Je ziet het eerder in de verschillende toepassingen op de data binnen een bedrijfscontext. Bijv. verschillende representaties van de onderliggende data voor de administratie, business-analist, data-analist.

Ik ben tot nu toe van mening dat in de ideale wereld developers alleen een database zouden mogen benaderen via stored procedures of views. Ik zie de noodzaak niet in dat een developer toegang moet hebben tot de tabellen zelf. Nog buiten dat er dan makkelijker fouten worden gemaakt kan het ook een security issue worden.

CurlyMo schreef op zaterdag 22 augustus 2020 @ 13:21:
De vraag is waar je de verantwoordelijkheid van de tests legt. Als je een database architectuur afdeling hebt die onafhankelijk van de software ontwikkelaars werken, dan kan ik me voorstellen dat je de views ook aan de database kant wil blijven valideren, zodat je niet van een ontwikkelaar hoort dat zijn unittest faalt, maar dat je dat zelf al door hebt voordat je een wijziging in het model aanbrengt.

De vraag is dan eerder waarom een ontwikkelaar de database überhaupt test? Dit hoort door de database architect of DBA gedaan te worden in mijn optiek.

CurlyMo schreef op zaterdag 22 augustus 2020 @ 13:21:
Om het moment dat je daadwerkelijk complexe SP, constraint, checks, triggers e.d. geïmplementeerd hebt, dan is het volgens mij niet anders dan software unittesten. Als jij zegt dat een postcode uit 4 cijfers en 2 letters bestaat, wat let je om een query te schrijven die specifiek 4 letters en 1 cijfer probeert in te voeren?

Vanuit data analyse schrijf ik veel complexe SQL t.b.v. data transformaties of data te her-modelleren. Om te testen of input / output goed wordt getransformeerd schrijf ik gewoon een input dataset en een output dataset. Daar laat ik de query op los en vervolgens vergelijk ik de twee. Dat is prima te scripten in elke willekeurige programmeertaal.

Maar waarom ga je een programmeertaal gebruiken voor iets dat op databaseniveau kan? Je zit er dan gelijk mee dat je een verbinding naar de database moet opzetten en dus al niet meer in isolatie de test uitvoert. Je bent dan dus al niet meer aan het unit testen. Voor een unit test moet je toch echt in de database zelf blijven.

[scosec]

Wij gebruiken onderstaand framework voor onze BI oplossing voor de geïnteresseerden : http://www.nbi.io/

[Koffie32]

scosec schreef op zaterdag 22 augustus 2020 @ 14:52:
Wij gebruiken onderstaand framework voor onze BI oplossing voor de geïnteresseerden : http://www.nbi.io/

Ziet er veel belovend uit van wat ik zie. Maar dit gebruikt dus op de achtergrond C# waarbij er als nog een verbinding met C# moet worden opgezet naar de database?

Wel iets waar ik mee ga rommelen denk ik.

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 14:46:
[...]

Ik ben tot nu toe van mening dat in de ideale wereld developers alleen een database zouden mogen benaderen via stored procedures of views. Ik zie de noodzaak niet in dat een developer toegang moet hebben tot de tabellen zelf. Nog buiten dat er dan makkelijker fouten worden gemaakt kan het ook een security issue worden.

Ik het categorische probleem niet van ontwikkelaars die tabellen direct benaderen. In de meeste databases zijn de authorisatie mogelijkheden ook niet veel anders voor tabellen dan voor views. Daarnaast moet vooral je datamodel daar aanleiding voor geven. Als je bijv. een data-vault model hebt gemaakt, dan is dat inderdaad minder gangbaar en gaat men er vanuit dat je contextuele representaties maakt middels views. Net zo goed als een eventsourcing model veelal gepaard gaat met een CQRS (Command Query Responsibility Segregation), waardoor je alsnog een scheiding hebt tussen je niveaus van abstractie.

De vraag is dan eerder waarom een ontwikkelaar de database überhaupt test? Dit hoort door de database architect of DBA gedaan te worden in mijn optiek.

Simpelste antwoord is al eerder gegeven. In veel ontwikkelteams is die scheiding niet zo hard aanwezig waardoor de ontwikkelaars ook de rol van DBA of database architect vervullen.

Daarnaast heb je twee rollen die de eisen van een klant proberen te realiseren. De database-architect in zijn model en de solution-architect in de softwarematige veronderstelde inrichting. Aangezien de software ontwikkelaar waarschijnlijk alle eisen wel een keer 'fysiek' behandeld in zijn code lijkt het me ook logischer dat die erop test. Een database architect implementeert de wensen vooral abstract en theoretisch. Het is de ontwikkelaar die hem test door hem in gebruik te nemen. Bij dingen die heel specifiek in een database-model worden opgepakt zoals bepaalde constraints of modelmatige inrichting zie ik wel weer de rol van de DBA voor de unittests.

Maar waarom ga je een programmeertaal gebruiken voor iets dat op databaseniveau kan?

Als ik in plpgsql werk dan vind ik dat bijna programmeren

[Ed Vertijsment]

Ik zit dit topic op de zijlijn te volgen en ik heb de indruk dat TS nu op school aan het leren is wat constraints en stored procedures zijn en een hoe je ze kan testen. Om er vervolgens achter te komen dat, dat in de praktijk (in mijn ervaring) bijna nooit gebeurt. Constraints en testen zijn hartstikke goed maar in de praktijk worden ze denk ik gewoon anders gebruikt.

1. Veel datamodellen zijn code-first.

Dat wil zeggen dat er in de software een datamodel staat uitgeschreven, en dat vanuit daar SQL wordt gegenereerd. De developer raakt vervolgens zelden de database aan. Ook constraints worden gegenereerd, en dat is getest in het framework, de werking ervan in de database, dat hoef je dus niet zelf nog een keer te doen.

2. Logica hoort in de applicatie, niet in de database.

Een database is voor veel developers, gewoon een bak met informatie, niet meer niet minder. Als er bij ons op kantoor iemand stiekem logica in de database (ver)stopt gaan er stevige gesprekken gevoerd worden. Staat dat in git? Is het duidelijk wat er gebeurt? Is het zichtbaar? Nee.

3. Waarom nog een test tool?

Hoe je het ook wil noemen, unit of intergratie test. Het doel is simpel, testen of je software werkt. Hoe meer tools jij opstapelt om dat resultaat te bereiken, hoe meer tijd het kost om at te beheren, hoe duurder het wordt.

Je kunt prima in een normale test kwijt dat je iets ongeldigs naar de database wil schrijven en kijken of er een error terugkomt. Ik zie geen noodzaak om hier een specifiek tooltje voor in te zetten.

[CurlyMo]

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:01:
Om er vervolgens achter te komen dat, dat in de praktijk (in mijn ervaring) bijna nooit gebeurt.

Opnieuw is dat sterk afhankelijk van de organisatie waar je werkt. Ik ben bij genoeg projecten betrokken geweest waarbij het datamodel een eigen product was opgeleverd door een database architect en de software daarboven op ook. Waarin de scheiding van invloed tussen beide werelden vrij strikt was. Met name omdat het datamodel in staat moest zijn heel zuivere audit en logtrails mogelijk te maken en het gedoe dat dat opleverde voor de ontwikkelaars daarbij ondergeschikt was. Daarbij werden wel views met triggers gebruikt om het leven van de ontwikkelaars iets te verzachten

[Ed Vertijsment]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 15:08:
[...]

Opnieuw is dat sterk afhankelijk van de organisatie waar je werkt. Ik ben bij genoeg projecten betrokken geweest waarbij het datamodel een eigen product was opgeleverd door een database architect en de software daarboven op ook. Waarin de scheiding van invloed tussen beide werelden vrij strikt was. Met name omdat het datamodel in staat moest zijn heel zuivere audit en logtrails mogelijk te maken en het gedoe dat dat opleverde voor de ontwikkelaars daarbij ondergeschikt was. Daarbij werden wel views met triggers gebruikt om het leven van de ontwikkelaars iets te verzachten

Ik zeg ook niet, dat het niet gebeurt. Maar zelfs in dat geval heb je een view waar je software mee kan praten. En logica me kan uitvoeren, zodat niet alles in stored procedures moet.

Je kan misschien van alles met stored procedures, soms vast ook wel nuttige dingen. Maar het verhaal van TS doet mij denken aan "niet omdat het moet, maar omdat het kan".

[The Eagle]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 14:41:
[...]

Het is niet alleen theoretisch met constraints af te dwingen maar ook praktisch.

Les 1 in de ICT: dat iets automatisch kan en praktisch lijkt, wil niet zeggen dat dat dan ook per definitie een goed idee is

Als je die definitie van een database aanhoudt dan neem ik aan dat je een afkeur hebt van relatonele databases? Volgens die definitie heb je namelijk genoeg aan een documentdatabase voor welk type applicatie/software dan ook.

Ik heb nergens een afkeer van. Relationeel, documentDB, timeseries DB, columnar, etc: ze hebben allemaal een ander ding waar ze goed in zijn. Voor OLTP toepassingen (applicaties) is een RDBMS de meestgebruikte. Alles als document opslaan kan idd prima, maar dan zit je weer met impact op updates te kijken. Oh ja, en niet al die dingen zijn ook per definitie ACID compliant, wat je meestal bij een multi user applicatie wel graag wilt

Waarom moet je dan immers nog verwijzende of primaire sleutels hebben? Dwing dat dan ook gewoon af op applicatieniveau.

Kan ook prima. Heck, ik heb 13 jaar gewerkt met een ERP systeem (PeopleSoft, wereldmarktleider in HR ERP) dat exact zo werkte. Slechts primaire sleutels op tabellen,en evt extra samengestelde sleutels puur voor extra indexen. Ca 50.000 tabellen per database, 75k-100k gebruikers concurrent wereldwijd. Gaat allemaal prima,
RDBMS'en zijn inherent goed en snel in het afdwingen van referentiële integriteit, daar valt in applicatielogica niet echt tegenop te programmeren. Dus die gebruik je wel. Voor dingen die echte applicatie- of bedrijfslogica af moeten dwingen: lekker bij de applicatie(ontwikkelaar) houden.

Overigens: nofi, maar je komt redelijk stellig over in hetgeen je schrijft. Het komt op mij over alsof je denkt dat je nu de wijsheid in pacht hebt doordat je net iets op school hebt geleerd, en dat nu de ultieme waarheid voor je lijkt te zijn. Je trekt vrij snel de kennis en ervaring van mensen hier in twijfel iig. Ik denk niet dat dat je bedoeling is en dat je oprecht een vraag hebt. Maar realiseer jezelf wel dat als je (als relatieve nieuwkomer in het vakgebied) een vraag neerlegt waarbij je zelf meent een beter antwoord te hebben, wij ook zoiets hebben van "he snotneus, je moet nog veel leren, maar als je het niet wilt horen wordt hem dat niet".

[Koffie32]

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:01:
Ik zit dit topic op de zijlijn te volgen en ik heb de indruk dat TS nu op school aan het leren is wat constraints en stored procedures zijn en een hoe je ze kan testen. Om er vervolgens achter te komen dat, dat in de praktijk (in mijn ervaring) bijna nooit gebeurt. Constraints en testen zijn hartstikke goed maar in de praktijk worden ze denk ik gewoon anders gebruikt.

Ik hoop dat ik dat toch onderhand wel kan. Ik probeer inderdaad te ontdekken hoe dit stand houdt in de praktijk.

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:01:
1. Veel datamodellen zijn code-first.

Dat wil zeggen dat er in de software een datamodel staat uitgeschreven, en dat vanuit daar SQL wordt gegenereerd. De developer raakt vervolgens zelden de database aan. Ook constraints worden gegenereerd, en dat is getest in het framework, de werking ervan in de database, dat hoef je dus niet zelf nog een keer te doen.

Ik denk dat hier het verschil ligt. Bij de database vakken gaan we toch vaak uit van Data Model Driven Development.

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:01:
2. Logica hoort in de applicatie, niet in de database.

Een database is voor veel developers, gewoon een bak met informatie, niet meer niet minder. Als er bij ons op kantoor iemand stiekem logica in de database (ver)stopt gaan er stevige gesprekken gevoerd worden. Staat dat in git? Is het duidelijk wat er gebeurt? Is het zichtbaar? Nee.

Dat is waar het verschil zit lijkt het, developers. Ik vermoed inderdaad dat bij de meeste bedrijven de database beheert wordt door developers die weinig affiniteit hebben met databases. In de meeste gevallen zal dat weinig problemen opleveren.

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:01:
3. Waarom nog een test tool?

Hoe je het ook wil noemen, unit of intergratie test. Het doel is simpel, testen of je software werkt. Hoe meer tools jij opstapelt om dat resultaat te bereiken, hoe meer tijd het kost om at te beheren, hoe duurder het wordt.

Je kunt prima in een normale test kwijt dat je iets ongeldigs naar de database wil schrijven en kijken of er een error terugkomt. Ik zie geen noodzaak om hier een specifiek tooltje voor in te zetten.

Minder afhankelijkheden.

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:34:
[...]
Ik denk dat hier het verschil ligt. Bij de database vakken gaan we toch vaak uit van Data Model Driven Development.

Ik kan me er wel een voorstelling van maken, maar wat wordt daar precies bij jullie op school mee bedoelt?

[Koffie32]

Ed Vertijsment schreef op zaterdag 22 augustus 2020 @ 15:10:
Ik zeg ook niet, dat het niet gebeurt. Maar zelfs in dat geval heb je een view waar je software mee kan praten. En logica me kan uitvoeren, zodat niet alles in stored procedures moet.

Je kan misschien van alles met stored procedures, soms vast ook wel nuttige dingen. Maar het verhaal van TS doet mij denken aan "niet omdat het moet, maar omdat het kan".

Nah, die stelling gaat niet op wat mij betreft. De vraag was simpel of het wordt toegepast. Maar het lijkt er op dat dit in ieder geval bij de meeste systemen niet gebeurd.

Met een view kun je aardig uit de voeten wat betreft weergaven maar ik zal niet snel uit mijzelf je update rechten toekennen op een view. Dat zal als het aan mij ligt toch echt via een stored procedure gaan.

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:38:
[...]
Met een view kun je aardig uit de voeten wat betreft weergaven maar ik zal niet snel uit mijzelf je update rechten toekennen op een view. Dat zal als het aan mij ligt toch echt via een stored procedure gaan.

Als je een RUD trigger hebt op een view dan is het inderdaad gangbaar hem af te laten handelen middels een SP, maar je RUD rechten staan dan toch primair op je view, niet op je SP.

[Koffie32]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 15:37:
[...]

Ik kan me er wel een voorstelling van maken, maar wat wordt daar precies bij jullie op school mee bedoelt?

Voor een relationeel OLTP systeem (geen DV of datamart) komt dit neer op (enige nuance weggelaten):

1. Achterhaal de feiten (predikaten) waaruit het proces bestaat en de bedrijfsregels.
2. Analyseer de feiten (doen wij met FOM), achterhaal entiteiten, attributen en relaties en kom tot een CDM (bedrijfregels worden nu constraints).
3. Zet CDM om in een PDM (bedrijfsregels zijn nu intgrity rules).
4. Genereer de database en implementeer bedrijfsregels.

[Ed Vertijsment]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:34:
[...]

Ik hoop dat ik dat toch onderhand wel kan. Ik probeer inderdaad te ontdekken hoe dit stand houdt in de praktijk.

Prima, in de praktijk wordt echt wel het een en ander aan db features gebruikt, maar vaak gegenereerd, en zelden (los) getest middels zo'n tool.

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:34:
[...]

Ik denk dat hier het verschil ligt. Bij de database vakken gaan we toch vaak uit van Data Model Driven Development.

Afhankelijk van wat je exact met "Data Model Driven Development" bedoelt natuurlijk, wij werken vaak ook als eerste een model uit. Maar het is natuurlijk niet zo dat een model altijd een stuk SQL moet zijn, bij ons is dat (na eventueel een schets op papier/whiteboard) python vanwaar SQL wordt gegenereerd. Voordeel: het framework (Django) genereerd migraties om eventueel terug te kunnen gaan.

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:34:
[...]

Dat is waar het verschil zit lijkt het, developers. Ik vermoed inderdaad dat bij de meeste bedrijven de database beheert wordt door developers die weinig affiniteit hebben met databases. In de meeste gevallen zal dat weinig problemen opleveren.

Het is niet zo dat developers (perse) geen affiniteit met databases hebben. Maar de applicatie is simpelweg leidend in logica. Je wilt gewoon 1 codebase hebben met alle logica en alle regels voor het verwerken van code. Als de database opeens dingen gaat doen kom je voor verassingen te staan.

Dit soort stored procedures etc. zullen zeker hun nut hebben op bepaalde plekken, maar zolang het er niet is wegen de nadelen niet op tegen de voordelen.

Koffie32 schreef op zaterdag 22 augustus 2020 @ 15:34:
[...]

Minder afhankelijkheden.

Ik vind zo'n tool juist weer een afhankelijkheid. Als mijn bestaande test infra kan vaststellen dat iets wat niet moet kunnen niet kan is dat prima. Hoef ik geen extra tool van. Als mijn systeem niet met de db kan verbinden om dat vast te stellen heb ik een ander probleem.*

*De test db is niet de echte db natuurlijk.

[Koffie32]

The Eagle schreef op zaterdag 22 augustus 2020 @ 15:12:
Overigens: nofi, maar je komt redelijk stellig over in hetgeen je schrijft. Het komt op mij over alsof je denkt dat je nu de wijsheid in pacht hebt doordat je net iets op school hebt geleerd, en dat nu de ultieme waarheid voor je lijkt te zijn. Je trekt vrij snel de kennis en ervaring van mensen hier in twijfel iig. Ik denk niet dat dat je bedoeling is en dat je oprecht een vraag hebt. Maar realiseer jezelf wel dat als je (als relatieve nieuwkomer in het vakgebied) een vraag neerlegt waarbij je zelf meent een beter antwoord te hebben, wij ook zoiets hebben van "he snotneus, je moet nog veel leren, maar als je het niet wilt horen wordt hem dat niet".

Ow, ik weet het antwoord niet beter. Nog sterker ik denk niet dat er één antwoord is.

Ook onderling is er bij de leden geen overeenstemming hoor.

[Woy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:58:
[...]

Waarom neem je de constraints dan nogmaals op in je softwaremodel? Aannemelijk is toch dat het datamodel al eerder bestaat?

Ik zeg ook niet perse in een software model, maar zowel bij een DB first als bij een code first aanpak zul je het het liefst niet direct in de DB aanpassen maar in een tool. Of je dan de DB genereert of de data access code haalt niet zoveel uit.

Maar sowieso de aanname dat het datamodel eerst bestaat vind ik al niet juist. Natuurlijk zul je eerst data modelleren, maar daar zou ik niet perse bij de storage beginnen maar bij het domein, het storage data model is daar een afgeleide van.

[Woy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 11:46:
[...]

Ik denk dat dit met name het antwoord is. Ik vermoed dat het nog een te nieuw concept is.

Ik hou de reacties bijna niet meer bij.

Ik denk helemaal niet dat het een te nieuw concept is, maar dat het gewoon niet zoveel toegepast wordt, omdat meestal de business rules niet in de DB terecht komen. Bij veel legacy systemen zie je dan nog wel, en daar zal inderdaad niet zo snel een unit test suite tegen aan gehangen worden.

[Kalentum]

Woy schreef op zaterdag 22 augustus 2020 @ 17:44:
[...]

Ik zeg ook niet perse in een software model, maar zowel bij een DB first als bij een code first aanpak zul je het het liefst niet direct in de DB aanpassen maar in een tool. Of je dan de DB genereert of de data access code haalt niet zoveel uit.

Maar sowieso de aanname dat het datamodel eerst bestaat vind ik al niet juist. Natuurlijk zul je eerst data modelleren, maar daar zou ik niet perse bij de storage beginnen maar bij het domein, het storage data model is daar een afgeleide van.

Hoe zit bij jou dan zo'n data model eruit?

Bij mij zijn het gewoon tabellen en velden met bijbehorende types. Ik zit direct een relationeel data model te bedenken. Moet er niet aan denken om voor elke feature eerst nog eens te besluiten wat voor storage ik moet gaan gebruiken. Dat is in principe gewoon een RDBMS tenzij redenen.

[Woy]

Kalentum schreef op zaterdag 22 augustus 2020 @ 17:51:
[...]
Hoe zit bij jou dan zo'n data model eruit?

Daar heb ik legio mogelijkheden voor gezien. Bij wat nieuwere projecten zie ik veel code-first, waar d.m.v. classes en configuratie een DB wordt gespecificeerd.

Maar er zij ook zat modelerings tools waar je gewoon een DB kunt specificeren, die dan automatisch create/alter scripts kan genereren.

Natuurlijk kan het ook gewoon d.m.v. van handmatig scripts schrijven, maar dan nog wil je een goed systeem hebben om dat te version controllen, nieuwe DB's uit te rollen, en updates te verspreiden.

Uiteindelijk specificeer je natuurlijk op alle manieren gewoon tabellen, velden, constraints e.d, maar er zijn legio manieren over hoe je dat vast kunt leggen. En sowieso zul je ergens vast moeten leggen hoe je database met je data access code relateert. Dat kun je volledig los vastleggen, of je gebruikt een tool die zorgt dat je code altijd met het schema van je DB matcht ( Dat kan door code uit je DB schema te genereren, of door je DB schema uit je code te genereren. Of door beide uit een overkoepelend model te genereren. )

Alle manieren hebben zo hun voors en tegens, dus het is een beetje afhankelijk van het project welke aanpak ik zelf zou kiezen. Maar in de projecten waar ik architect van ben, is wel altijd de stelregel dat er zo min mogelijk business logica in de DB hoort te zitten. Die heb ik liever gespecificeerd in een taal die daar beter voor geschikt is. Dat neemt niet weg dat ook in de DB constraints horen om de data-integriteit te bewaren, maar dat blijft meestal redelijk bij non-null checks, referentiële integriteit, uniqueness en max-length, en daar ga ik geen unit tests op DB niveau voor schrijven, want ik vertrouw de DB voldoende dat hij die gewoon afdwingt als ik ze specificeer.

[ Voor 21% gewijzigd door Woy op 22-08-2020 18:13 ]

[Kalentum]

Ah ok, ik werk zelden aan compleet nieuwe structuren dus het komst meestal aan op een migratiescript en een bijbehorende class (die zelf op basis van de DDL uitzoekt welke attributen en data types beschikbaar zijn). Dus feitelijk niet code first maar data-first. In de meest eenvoudige vorm is de bijbehorende class alleen maar een afgeleide van een tabelnaam (bv tabel 'users' heeft een class User)

[Koffie32]

@Kalentum @Woy leuk jullie discussie ook te lezen. Mag ik vragen wat jullie functieomschrijving is?

[Kalentum]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 21:30:
@Kalentum @Woy leuk jullie discussie ook te lezen. Mag ik vragen wat jullie functieomschrijving is?

Backend developer. Ik mag graag denken dat ik het bedrijf waar ik werk en het product dat we bieden verder help door slimme, kosteneffectieve, pragmatische, onderhoudbare en schaalbare oplossingen te bedenken.

[Koffie32]

Kalentum schreef op zaterdag 22 augustus 2020 @ 22:30:
Backend developer. Ik mag graag denken dat ik het bedrijf waar ik werk en het product dat we bieden verder help door slimme, kosteneffectieve, pragmatische, onderhoudbare en schaalbare oplossingen te bedenken.

Backend als in REST API's?

[gekkie]

Sowieso ontkom je er vaak niet aan om checks ook in de applicatie te verwerken, vaak zelfs in de (web)client code, niet zo zeer om iets af te dwingen, maar om nog een beetje fatsoenlijke user experience over te houden
(grey-outen van opties, fatsoenlijk omschreven melding retour etc.).

Neemt niet weg dat waar het enigzins mogelijk je constraints te forceren in je database, dit wel verstandig is.

Maar goed volgende theoretische vs praktijk discussie zou je DB normalisatie kunnen zijn

[ Voor 10% gewijzigd door gekkie op 22-08-2020 22:41 ]

[CurlyMo]

Kalentum schreef op zaterdag 22 augustus 2020 @ 17:51:
[...]
Bij mij zijn het gewoon tabellen en velden met bijbehorende types. Ik zit direct een relationeel data model te bedenken.

Waarmee je eigenlijk alsnog niks zegt

Uiteindelijk zijn alle ERD's gewoon tabellen met velden met types. Dan kan ik mezelf alsnog een paar dagen het hoofd breken hoe ik het beste een bepaalde domein vraag kan vertalen naar een goede set aan tabellen. Of zoals ooit leuk geïllustreerd in de Gay Marriage casus (die jammer genoeg niet meer te vinden is). Waar overigens genoeg op aan te merken was (ook door mij).

[Kalentum]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 22:34:
[...]

Backend als in REST API's?

Nou ja zo noemen ze bij ons iedereen die geen front-end doet. Maar ja ook dat, interne API's die de microservice architectuur bij elkaar houden. En natuurlijk de business logic achter die API's. Vooral dat laatste eigenlijk.

[michelvosje]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 22:40:
[...]
Uiteindelijk zijn alle ERD's gewoon tabellen met velden met types.

Nee... Een ERD kan vertaald worden naar een informatie model > relatie model > relationeel database schema.

[CurlyMo]

michelvosje schreef op zaterdag 22 augustus 2020 @ 22:44:
[...]

Nee... Een ERD kan vertaald worden naar een informatie model > relatie model > relationeel database schema.

Ok ok

[Kalentum]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 22:40:
[...]

Waarmee je eigenlijk alsnog niks zegt

Uiteindelijk zijn alle ERD's gewoon tabellen met velden met types. Dan kan ik mezelf alsnog een paar dagen het hoofd breken hoe ik het beste een bepaalde domein vraag kan vertalen naar een goede set aan tabellen. Of zoals ooit leuk geïllustreerd in de Gay Marriage casus (die jammer genoeg niet meer te vinden is). Waar overigens genoeg op aan te merken was (ook door mij).

Tuurlijk maar @Woy had het over de storage er later bij pakken terwijl dat bij ons niet echt een keuze is zeg maar. Dus mijn datamodel is al het specifieke smaakje dat we MySQL noemen. Ik schrijf een klein opzetje in Jira , doe een sanitiy check in het team en implementeer het.

Of ik begrijp je reactie niet...? Wat bedoel je precies?

[CurlyMo]

Kalentum schreef op zaterdag 22 augustus 2020 @ 22:52:
[...]
Dus mijn datamodel is al het specifieke smaakje dat we MySQL noemen.

MySQL is je database software waarbinnen een database model maakt. Of snap ik jou weer niet?

De vraag die @Koffie32 hier oproept hoe je omgaat met het opstellen van dat datamodel. Pas je unittests toe, is de data-architect 'onafhankelijk' van de ontwikkelaars, hoe pas je gelaagdheid toe (in context van autorisatie, business specifiek representaties, e.d.), enz.

[Koffie32]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 22:56:
MySQL is je database software waarbinnen een database model maakt. Of snap ik jou weer niet?

De vraag die @Koffie32 hier oproept hoe je omgaat met het opstellen van dat datamodel. Pas je unittests toe, is de data-architect 'onafhankelijk' van de ontwikkelaars, hoe pas je gelaagdheid toe (in context van autorisatie, business specifiek representaties, e.d.), enz.

Ik vermoed dat @Kalentum verwijst naar DDL als zijnde een datamodel en niet een CDM, PDM o.d..

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 23:08:
[...]

Ik vermoed dat @Kalentum verwijst naar DDL als zijnde een datamodel en niet een CDM, PDM o.d..

Wat een afkortingen allemaal zeg

Wat @michelvosje zegt ken ik nog, het informatie model, relatie model,relationeel database schema, maar al deze termen zeggen me (in theorie) weinig.

[michelvosje]

michelvosje schreef op zaterdag 22 augustus 2020 @ 22:44:
[...]

Nee... Een ERD kan vertaald worden naar een informatie model > relatie model > relationeel database schema.

Ik wil hier op aanvullen dat van links naar rechts eigenlijk een hoog-over/abstractie/conceptueel model naar implementatie is.
Er zijn dus methoden die het mogelijk maken om vanuit meta data deze modellen te produceren. Dus de definitie van je model ligt dan vastgelegd in data. Die data kan vervolgens met tools geconverteerd en geïnjecteerd worden in bijv. een RDMS als een schema. Model driven engineering maakt hier gebruik van. En let op: Data kun je genereren.

Ook zijn er tools beschikbaar om juist vanuit een database andersom een model op te bouwen. Van daaruit kun je verschillende richtingen uit. In-memory objecten en bijv. XML. Op die manier kun je vanuit een object georienteerde omgeving je database records als objecten benaderen. Vandaar dat ik in mijn voorbeeld dus gebruik heb gemaakt van Hibernate. Ook maakt dit het mogelijk om data uit databases automatisch te vertalen naar andere modellen.

[Kalentum]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 23:08:
[...]

Ik vermoed dat @Kalentum verwijst naar DDL als zijnde een datamodel en niet een CDM, PDM o.d..

Ik denk dat mijn kladje in Jira een CDM is en mijn DB migratie een PDM .

[Kalentum]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 22:56:
[...]

MySQL is je database software waarbinnen een database model maakt. Of snap ik jou weer niet?

Wat ik bedoelde is dat ik niet eerst een model kan bedenken en dan de beste storage er bij kan zoeken. De hele zut zit in MySQL dus ik moet het daar ook in stoppen. Omdat standaardisatie, 50 microservices enzo. Tenzij redenen om er van af te wijken.

[Woy]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 21:30:
@Kalentum @Woy leuk jullie discussie ook te lezen. Mag ik vragen wat jullie functieomschrijving is?

Afhankelijk van het project Software Architect/Lead Developer, en soms een beetje consultancy.

[Woy]

Kalentum schreef op zaterdag 22 augustus 2020 @ 23:23:
[...]
Omdat standaardisatie, 50 microservices enzo. Tenzij redenen om er van af te wijken.

Natuurlijk heeft standaardisatie zijn voordelen, maar als je er al zo hard vanuit gaat dan heb je de kans dat je last van tunnelvisie krijgt, en dus niet de juiste technologie kiest.

IMHO moet je altijd eerst even op een wat abstracter niveau kijken, en dan bepalen wat een goede strategie is. Als je bij een RDBMS uitkomt, en jullie altijd MySQL gebruiken is dat dan natuurlijk een logische keus. Juist bij microservices heb je de vrijheid om af te wijken waar dat uitkomt.

[ Voor 5% gewijzigd door Woy op 23-08-2020 12:33 ]

[Kalentum]

Woy schreef op zondag 23 augustus 2020 @ 12:32:
[...]

Natuurlijk heeft standaardisatie zijn voordelen, maar als je er al zo hard vanuit gaat dan heb je de kans dat je last van tunnelvisie krijgt, en dus niet de juiste technologie kiest.

IMHO moet je altijd eerst even op een wat abstracter niveau kijken, en dan bepalen wat een goede strategie is. Als je bij een RDBMS uitkomt, en jullie altijd MySQL gebruiken is dat dan natuurlijk een logische keus. Juist bij microservices heb je de vrijheid om af te wijken waar dat uitkomt.

Zeker heb je die vrijheid, maar die komt wel met een prijs. Als we NU product X niet gebruiken en morgen product X willen gaan gebruiken moet er ook wat gebeuren op het gebied van personeel (scholing of kennis binnen halen) en infrastructuur (deploy, configuraties, failover/backup/restore indien van toepassing etc, data anonimisatie). Het is niet gratis, zullen we maar zeggen. Een stuk software 24/7 in een high availability omgeving introduceren is niet triviaal.

[Woy]

Kalentum schreef op zondag 23 augustus 2020 @ 12:52:
[...]


Zeker heb je die vrijheid, maar die komt wel met een prijs. Als we NU product X niet gebruiken en morgen product X willen gaan gebruiken moet er ook wat gebeuren op het gebied van personeel (scholing of kennis binnen halen) en infrastructuur (deploy, configuraties, failover/backup/restore indien van toepassing etc, data anonimisatie). Het is niet gratis, zullen we maar zeggen. Een stuk software 24/7 in een high availability omgeving introduceren is niet triviaal.

Nee, mijn advies is ook zeker niet om maar polyglot development als doel te hebben, maar wel om een open blik te houden, en niet gefixeerd op MySQL te blijven steken omdat je dat altijd doet. En dan doel ik niet zozeer op het overstappen op een ander RDBMS, maar in sommige gevallen is een time-series DB beter, soms een no-sql DB, soms gewoon files op een disk.

[Kalentum]

Woy schreef op zondag 23 augustus 2020 @ 13:07:
[...]

Nee, mijn advies is ook zeker niet om maar polyglot development als doel te hebben, maar wel om een open blik te houden, en niet gefixeerd op MySQL te blijven steken omdat je dat altijd doet. En dan doel ik niet zozeer op het overstappen op een ander RDBMS, maar in sommige gevallen is een time-series DB beter, soms een no-sql DB, soms gewoon files op een disk.

Ja klopt. Dat valt inderdaad onder "goede redenen" om af te wijken. Als de data of het data gebruik niet zo goed bij relationele datamodellen past dan kunnen we inderdaad wel iets anders inzetten

[CurlyMo]

Woy schreef op zondag 23 augustus 2020 @ 13:07:
[...]
En dan doel ik niet zozeer op het overstappen op een ander RDBMS, maar in sommige gevallen is een time-series DB beter, soms een no-sql DB, soms gewoon files op een disk.

Of direct een data-virtualisatie aanpak

Kalentum schreef op zondag 23 augustus 2020 @ 12:52:
[...]
Een stuk software 24/7 in een high availability omgeving introduceren is niet triviaal.

Waarom hebben jullie (ooit) gekozen als MySQL als basis voor je data en niet (om in OSS te blijven) PostgreSQL?

[Kalentum]

CurlyMo schreef op zondag 23 augustus 2020 @ 13:22:
[...]

Of direct een data-virtualisatie aanpak


[...]

Waarom hebben jullie (ooit) gekozen als MySQL als basis voor je data en niet (om in OSS te blijven) PostgreSQL?

Voor mijn tijd. Mijn voorkeur heeft het niet. Ik denk dat het 12 jaar geleden als een vanzelfsprekende keuze werd gezien.

[CurlyMo]

Kalentum schreef op zondag 23 augustus 2020 @ 13:24:
[...]


Voor mijn tijd. Mijn voorkeur heeft het niet. Ik denk dat het 12 jaar geleden als een vanzelfsprekende keuze werd gezien.

Woy schreef op zaterdag 22 augustus 2020 @ 18:02:
[...]
[...] en daar ga ik geen unit tests op DB niveau voor schrijven, want ik vertrouw de DB voldoende dat hij die gewoon afdwingt als ik ze specificeer.

En dat was nu net bij MySQL van 12 jaar geleden niet vanzelfsprekend

[Fiander]

Unit testen van een database wil ik soort van nog wel eens gebruiken wanneer ik weer eens bij een 100 jaar oude applicatie storedprocedures/queries moet herschijven waar andere ontwikkelaars al meer dan 1000 manuur in hebben zitten aan bedrijfs logica. dan maak ik eerst unit testen waarmee ik alle logica van de storedprocedure/query probeer af te vangen, samen met een minimale tabelinhoud welke alle logica van de storedprocedure/query raakt.

zo is het gemakkelijker om de logica te doorgronden, en bij het herschijven zie je sneller of je dingen mist. en je hebt een gemakkelijke performance test meteen.

Maar feitelijk is dit unit testen van queries, en niet van de database zelf.

[Verwijderd]

ik had nog niet gehoord van unit tests op de database.

Wat ik wel eerder heb gezien in dit bericht en zelf ook heb ervaren is: houdt de database zo simpel mogelijk. Bij php (symfony) wordt het basismodel eerst gecreeerd. via mvc model houd je de logica waar gewenst en met crud vang je de specifieke pre / post condities af. dit wordt allemaal in de code gedaan omdat je niet en /en wilt (Zo min mogelijk) de serverside code (backend) bepaald immers wat er met de database en connectie gebeurd. die rechten heb je de backend gegeven. Deze rechten heeft dus ook plichten en die moeten worden getest.

De reden om de database dom te houden is capaciteit. Meerdere applicaties (ook al is het dezelfde applicatie) via een loadbalancer is makkelijker te onderhouden dan een complexe database. Nu pas zijn er systemen in de wereld goedkoop genoeg aan het worden om high traffic databases meer complex te laten worden.

Andere reden is: er zijn meer developers beschikbaar voor je bedrijf die de database onderhoud. En er zijn meer developers beschikbaar dan db architects.

Dus ik denk dat je een niche hebt gevonden, of het begint net omdat de computers/servers het nu aankunnen