[Databases] Ontwikkeling

[JKVA]

Binnenkort organiseert mijn werkgever een Java bijeenkomst, genaamd "Innoveer Jij Mee", met als onderwerpen "Up-to-database!" en "Open Source Licenties in de Praktijk".

De eerste sessie heeft mij de laatste paar dagen aan het denken gezet.

Ik merk namelijk dat de database in de praktijk vaak een ondergeschoven kindje is. Zo worden indexen vaak vergeten, wordt er vrij gemakkelijk gedaan over (not-null) constraints en wordt aan het ontwerp ook vrij weinig aandacht besteed.

Bovendien zie ik vaak dat wanneer een applicatie in productie staat, het heel lastig wordt om op een verantwoorde manier wijzigingen door te voeren in de database. Zeker als de applicatie al een tijdje online is en de database ver gevuld is.

Hoe gaan jullie om met de database als je een applicatie bouwt? Lopen jullie ook tegen deze problemen aan of hebben jullie methoden om dit te voorkomen?

Tenslotte, mocht je dit (en/of open source licenties) een interessant onderwerp vinden. 24 september is in de Jaarbeurs Utrecht de sessie. Opgeven kan via de site: spam. Daar staat ook verdere info. Ik ben iig benieuwd (vooral de discussie) en ga dus wel ff kijken.

Sorry, maar ik heb de url weggehaald. Als ik dit toelaat, dan moet ik dergelijke dingen in ieder topic toelaten. Je kan natuurlijk wel die site in je sig gaan opnemen.

[ Voor 8% gewijzigd door whoami op 06-09-2007 19:02 ]

[whoami]

De DB het ondergeschoven kindje ?
Ik denk dat dit afhangt van persoon tot persoon. Of laat het mij anders zeggen: een programmeur die weet waar hij mee bezig is, of iemand die echt weet wat software-ontwikkeling inhoudt, zal -in de gevallen wanneer er enterprise app's ontwikkeld worden- de DB echt niet als een ondergeschoven kindje gaan beschouwen.

Ikzelf probeer zoveel mogelijk aandacht te besteden aan een goed 'basis-ontwerp' (normalisatie), en ga ook de nodige constraints (unique / not null / etc... gaan leggen). Hetzlfde geldt voor indexen & performance tuning.

Het is natuurlijk wel zo dat men in het 'Domain Driven Design' paradigma de database vaak als een 'implementatie-detail' gaat beschouwen. Men gaat er vanuit dat de logica het belangrijkste is, en de manier waarop de gegevens opgeslagen worden, van ondergeschikt belang is.
Alhoewel ik een voorstander ben van 'DDD', vind ik dit standpunt eigenlijk onterecht. Het is nog steeds belangrijk dat je gegevens op een consistente manier opgeslagen worden, en dat de integriteit ervan bewaard wordt.

Als ik op m'n huidige project trouwens schema-wijzigingen moet doen aan de databank, dan ga ik daar redelijk consequent in te werk:
Het is zo dat m'n DB schema in Visio staat. Als er een schema-wijziging moet gebeuren, dan doe ik deze wijziging in Visio. Daarna genereer ik de DB vanuit Visio en doe ik mbhv de 'Redgate' tools een compare tussen het nieuwe en het oude schema. Daaruit komt dan een SQL Script dat ik beschouw als een patch om van versie n-1 naar versie n te gaan. (De versie waarin de DB zich bevind wordt ook door de DB zelf bijgehouden).
In bepaalde gevallen is het wel nog nodig dat ik een paar manuele wijzigingen doe aan dit gegenereerde script (om er bv voor te zorgen dat reeds bestaande gegevens in de nieuwe / aangepaste structuur kunnen opgenomen worden).
Daarna kan ik mijn db - patch gaan testen op m'n development database, of op m'n test-database. Indien dit goed gaat, vliegt m'n patch in VSS.

Op het geschikte moment kan ik dan deze nieuwe patch (of meerdere patches) laten uitvoeren op de productie-databank. (Hiervoor heb ik een klein applicatietje ontwikkeld die ervoor zorgt dat alle nodige patches in de juiste volgorde kunnen uitgevoerd worden).

[SKiLLa]

JKVA schreef op donderdag 06 september 2007 @ 18:39:

... Ik merk namelijk dat de database in de praktijk vaak een ondergeschoven kindje is. ...

Dat merk ik ook wel vaak, maar in bijna alle gevallen is het bijbehorend dev. niveau zelf ook droevig. Anders gezegd: ik heb (goede) professionele programmeurs nog nooit de DB als ondergeschoven kindje zien behandelen ...

En wat je ook vaak tegen komt - ipv. het gebrek aan indexen - is juist een overkill aan (zinloze) indexen.
Soms zelfs meer dan velden in de betreffende tabel

[JKVA]

whoami schreef op donderdag 06 september 2007 @ 19:01:
De DB het ondergeschoven kindje ?
Ik denk dat dit afhangt van persoon tot persoon. Of laat het mij anders zeggen: een programmeur die weet waar hij mee bezig is, of iemand die echt weet wat software-ontwikkeling inhoudt, zal -in de gevallen wanneer er enterprise app's ontwikkeld worden- de DB echt niet als een ondergeschoven kindje gaan beschouwen.

Daar ben ik het ook mee eens. Ik zie de database ook als minimaal even belangrijk als de applicatie zelf. Een goed opgezette DB kan je leven flink aangenamer maken. Sterker nog, de meeste databases leven langer dan de applicaties.

Maar als ik om me heenkijk, zie ik dat velen toch moeite hebben om verantwoord met een database om te gaan. Zelfs grote bedrijven met IT afdelingen.

Ikzelf probeer zoveel mogelijk aandacht te besteden aan een goed 'basis-ontwerp' (normalisatie), en ga ook de nodige constraints (unique / not null / etc... gaan leggen). Hetzlfde geldt voor indexen & performance tuning.

Het is natuurlijk wel zo dat men in het 'Domain Driven Design' paradigma de database vaak als een 'implementatie-detail' gaat beschouwen. Men gaat er vanuit dat de logica het belangrijkste is, en de manier waarop de gegevens opgeslagen worden, van ondergeschikt belang is.
Alhoewel ik een voorstander ben van 'DDD', vind ik dit standpunt eigenlijk onterecht. Het is nog steeds belangrijk dat je gegevens op een consistente manier opgeslagen worden, en dat de integriteit ervan bewaard wordt.

True, maar als ik kijk naar de huidige generatie (Java) developers, dan zie ik dat (los van DDD) deze mening niet door iedereen gedeeld wordt. Niemand ziet de database nog, want daar hebben we Hibernate voor. Als je een keer een SQL query schrijft, wordt dat als "vies" ervaren.

Als ik op m'n huidige project trouwens schema-wijzigingen moet doen aan de databank, dan ga ik daar redelijk consequent in te werk:
Het is zo dat m'n DB schema in Visio staat. Als er een schema-wijziging moet gebeuren, dan doe ik deze wijziging in Visio. Daarna genereer ik de DB vanuit Visio en doe ik mbhv de 'Redgate' tools een compare tussen het nieuwe en het oude schema. Daaruit komt dan een SQL Script dat ik beschouw als een patch om van versie n-1 naar versie n te gaan. (De versie waarin de DB zich bevind wordt ook door de DB zelf bijgehouden).
In bepaalde gevallen is het wel nog nodig dat ik een paar manuele wijzigingen doe aan dit gegenereerde script (om er bv voor te zorgen dat reeds bestaande gegevens in de nieuwe / aangepaste structuur kunnen opgenomen worden).
Daarna kan ik mijn db - patch gaan testen op m'n development database, of op m'n test-database. Indien dit goed gaat, vliegt m'n patch in VSS.

Op het geschikte moment kan ik dan deze nieuwe patch (of meerdere patches) laten uitvoeren op de productie-databank. (Hiervoor heb ik een klein applicatietje ontwikkeld die ervoor zorgt dat alle nodige patches in de juiste volgorde kunnen uitgevoerd worden).

Mja, dat klinkt wel als iets dat werkt. Maar hoe ga je om met wijzigingen i.p.v. gewoon een veld toevoegen? Dat comparen levert namelijk wel een lijst aanpassingen op, maar nog geen DDL die je direct kunt draaien op productie. Het zijn namelijk "create" en geen "alter" statements. Maar goed, die kunnen eventueel met de hand gemaakt worden op basis van de verschillenlijst.

Bovendien zie ik hier nog geen oplossing in voor het terugdraaien van een wijziging. Of is dat een kwestie van backuppen? Maar dan ben je je data kwijt die is toegevoegd na de wijziging...

Ik merk dat het in projecten doorgaans een crime is om hiermee om te gaan. En dan vooral het versiebeheer...

[Verwijderd]

Helemaal mee eens, de goede ontwikkelaars/architecten e.d. beschouwen de database niet als ondergeschoven kindje, dat heeft natuurlijk ook een goede reden! Maar je kan nog zo'n goed datamodel hebben, als één programmeur verkeerd omgaat met queries kan de performance erg hard achteruit gaan. (Vaker gezien in de praktijk!)

Een presentatie over Open Source licenties is ook wel handig, je ziet tegenwoordig te vaak dat mensen gewoon alles wat OS is maar gebruiken "want het is toch open source!?". Ze vergeten vaak dat er dan nog steeds wel regels aanzitten. Zeker bij virale licenties kan dat heel vervelend zijn. Al zullen de meeste mensen die iets onder een virale OS-licentie releasen je niet zo snel aanklagen, het zou wel kunnen..!

[JKVA]

Verwijderd schreef op vrijdag 07 september 2007 @ 09:23:
Helemaal mee eens, de goede ontwikkelaars/architecten e.d. beschouwen de database niet als ondergeschoven kindje, dat heeft natuurlijk ook een goede reden! Maar je kan nog zo'n goed datamodel hebben, als één programmeur verkeerd omgaat met queries kan de performance erg hard achteruit gaan. (Vaker gezien in de praktijk!)

Mja, ik weet nog niet de inhoud van de presentatie, maar ik hoop wel iets te horen over hoe je je processen/procedures/tools goed kunt inregelen, dat zelfs het gedrag van (junior?) ontwikkelaars niet tot grote problemen kan leiden.

Ik merk namelijk dat in het begin van een project de database wel goed bijgehouden wordt, maar als meerdere mensen aanpassingen gaan doen, worden op den duur wijzigingen vergeten. En omdat de applicatie vaak direct afhankelijk is van de db structuur (en soms zelfs de inhoud, zoals bij stamtabellen) kan het gemakkelijk gebeuren dat het tot problemen leidt.

Vooral bij ad-hoc werk zoals productiepatches merk ik dat niet altijd gestructureerd gewerkt wordt, met als gevolg problemen op de langere termijn.

Beheer van de DB bij 1 persoon beleggen kan een optie zijn, maar dan ben je afhankelijk van die ene persoon. Beheer bij meerdere personen leggen, leidt vaak tot ongecoordineerd werk...

Een presentatie over Open Source licenties is ook wel handig, je ziet tegenwoordig te vaak dat mensen gewoon alles wat OS is maar gebruiken "want het is toch open source!?". Ze vergeten vaak dat er dan nog steeds wel regels aanzitten. Zeker bij virale licenties kan dat heel vervelend zijn. Al zullen de meeste mensen die iets onder een virale OS-licentie releasen je niet zo snel aanklagen, het zou wel kunnen..!

True, bij standalone tools zoals MySQL maakt het niet zo veel uit dat het GPL is, maar bijvoorbeeld een framework... Dat is vragen om problemen.

[Janoz]

Het probleem is eerder dat er eigenlijk helemaal niet zo heel veel goede ontwikkelaars en architecten zijn. Neem daarnaast mee dat voor databases vaak de volgende twee dingen gelden:

* Hun lifetime is way langer dan alle applicaties en een database overleefd meerdere 'nieuwe inzicht hypes en stromingen'
* Initieel zijn ze vaak opgezet als prototype om te kijken of het wat is en daarna uitgegroeid tot 'mission critical'

Het 'laten we gewoon eens helemaal from scratch beginnen want de aude rommel is daadwerkelijk oude rommel geworden' kun je niet tot bijna niet toepassen op databases waardoor ze uitgroeien tot wat je nu vaak in grote organisaties ziet.

[Verwijderd]

Janoz: Erg waar ja... het enige wat je zou kunnen doen is een nieuw datamodel opzetten en view creëren voor de oude applicaties, maar nog is dat bijna nooit een optie. Ik heb het geluk dat we voor de nieuwe klant een nieuwe model mogen maken.

Ik heb zowieso grote problemen met programmeurs die net beginnen in het vak en alleen maar kunnen programmeren. Behalve als je echt puur de weblaag doet en niks anders zou dat kunnen, maar de rest van de mensen MOET gewoon database kennis hebben. Het is bijna altijd de bottleneck in de applicatie omdat het meestal minder schaalbaar is. Het repliceren van applicatieservers werkt prima, maar ze gebruiken allemaal dezelfde dataset, hoe groot je database-cluster ook is. Kennis van queries opstellen, joins, groeperen, sorteren, indexes, views... critical in je applicatie. Want ook al gebruikt je junior programmeur tools als Hibernate/Toplink e.d. dat maakt het alleen maar makkelijker om verkeerde joins te doen.

Ben nu wel erg benieuwd geworden wat ze precies gaan vertellen in de jaarbeurs, ik kom zeker langs. De tweakertjes hier zijn critisch genoeg, hopelijk is hetzelfde publiek aanwezig in de jaarbeurs, dan krijgen we nog leuke discussies haha.

[Janoz]

Zullen we het in dit topic vooral hebben over het aangesneden database onderwerp? Als we het ook over de meeting en OS licenties gaan hebben gaat het allemaal een beetje door elkaar lopen. Voor het OS licenties onderdeel kan eventueel een appart topic geopend worden.


Dit topic past daarnaast beter in SEA.

[Verwijderd]

Om het dan maar puur database te houden, we gaan op ons project Liquibase gebruiken. Zijn er hier mensen met Liquibase ervaring?

Mocht je het niet kennen, een korte beschrijving:
In Liquibase leg je de opzet van je database vast in XML. Opzich ben ik geen groot voorstander van XML, maar hier is het wel goed op zijn plaats. Liquibase kan vanuit deze XML je database genereren en aanpassen. Het grote voordeel hiervan is dat alle wijzigingen gewoon je SCM in gaan. Alle programmeurs krijgen de nieuwe XML binnen en dmv een Ant scriptje wordt direct hun database bijgewerkt met de nieuwe code. Als je dus een oude branch uitcheck zal je ook de oude database-definitie binnenhalen. Liquibase kan opgezet worden om alleen wijzigingen door te voeren zodat de data behouden wordt, of compleet een nieuwe database genereren.

Wat ik er zover van gezien heb vind ik het een erg goede oplossing waar ik al tijden naar opzoek was. Ik vind namelijk dat al dat soort rand-software bijgehouden zou moeten worden vanuit je SCM zodat de ontwikkelaars niet zelf databases hoeven aan te passen. Hetzelfde geldt overigens voor dingen als applicationserver-instellingen e.d.

[JKVA]

Verwijderd schreef op vrijdag 07 september 2007 @ 10:58:
Om het dan maar puur database te houden, we gaan op ons project Liquibase gebruiken. Zijn er hier mensen met Liquibase ervaring?

Mocht je het niet kennen, een korte beschrijving:
In Liquibase leg je de opzet van je database vast in XML. Opzich ben ik geen groot voorstander van XML, maar hier is het wel goed op zijn plaats. Liquibase kan vanuit deze XML je database genereren en aanpassen. Het grote voordeel hiervan is dat alle wijzigingen gewoon je SCM in gaan. Alle programmeurs krijgen de nieuwe XML binnen en dmv een Ant scriptje wordt direct hun database bijgewerkt met de nieuwe code. Als je dus een oude branch uitcheck zal je ook de oude database-definitie binnenhalen. Liquibase kan opgezet worden om alleen wijzigingen door te voeren zodat de data behouden wordt, of compleet een nieuwe database genereren.

Wat ik er zover van gezien heb vind ik het een erg goede oplossing waar ik al tijden naar opzoek was. Ik vind namelijk dat al dat soort rand-software bijgehouden zou moeten worden vanuit je SCM zodat de ontwikkelaars niet zelf databases hoeven aan te passen. Hetzelfde geldt overigens voor dingen als applicationserver-instellingen e.d.

Mja, XML of DDL is volgens mij lood om oud ijzer. Volgens mij zit het probleem niet zozeer in het dataformaat. Zoals whoami namelijk al aangaf, de SQL create scripts kun je ook gewoon onder versiebeheer brengen.
Het probleem is volgens mij dat de meeste 'developers' slordig omgaan met de wijzigingen waardoor niemand meer van elkaar weet wat er gebeurd is. Automatische tooling zou dan handig zijn.

Daarnaast moet je bijhouden welke patches overal doorgevoerd zijn. Ik zou zeggen, commentaarregels in het DDL bestand zelf. En dat dan weer in de CVS of VSS ofzo.

[dip]

JKVA schreef op vrijdag 07 september 2007 @ 12:20:
[...]

Mja, XML of DDL is volgens mij lood om oud ijzer. Volgens mij zit het probleem niet zozeer in het dataformaat. Zoals whoami namelijk al aangaf, de SQL create scripts kun je ook gewoon onder versiebeheer brengen.
Het probleem is volgens mij dat de meeste 'developers' slordig omgaan met de wijzigingen waardoor niemand meer van elkaar weet wat er gebeurd is. Automatische tooling zou dan handig zijn.

Daarnaast moet je bijhouden welke patches overal doorgevoerd zijn. Ik zou zeggen, commentaarregels in het DDL bestand zelf. En dat dan weer in de CVS of VSS ofzo.

De oorzaak van dat probleem is uiteenlopend en kan variëren van het gebrek aan kennis tot het gebrek aan voorgedefinieerde processen. Begin met het opstellen van een process voor database wijzigingen, en handhaaf dit proces binnen het ontwikkelteam. Wanneer iedereen het plan volgt, is niet iedereen afhankelijk van een persoon die de taak als DBM heeft, maar gaat het toch gestructureerd. Tooling doet er dan niet zoveel meer toe.

[ Voor 4% gewijzigd door dip op 07-09-2007 12:52 ]

[Janoz]

Wat ik eigenlijk mis is een goede diff tool voor sql scripts. Voor programmacode kun je keurig diff's maken waardoor je simpel kunt upgraden naar een volgende versie. Ik ben nog geen goede tool tegen gekomen die een verschil in create scripts kan omzetten naar een alter table command.

Database wijzigingen moeten verder gewoon opgenomen worden in de hele release procedure. Ook voor de databases die je de volledige otap straat in te rechten. Zorg verder dat je op alle systemen snel een backup terug kan zetten, dan kun je op test al kijken of het database changescript wel alle verwachte aanpassingen doet. Zorg er daarnaast ook voor dat er regelmatig een (geannonimiseerde en eventueel ingekrompen) versie van productie op de rest uitgerold wordt om alles een beetje synchroon te houden.

Zeker in de wat kleinere trajectjes zie je dat de database naast productie, ook nog test en acceptatie is. Soms zie je onderscheid, maar dan is het vaak ontwikkel test en acceptatie op de ene database en productie op de andere. Je hebt dan nergens de ruimte om je upgrade script te kunnen testen.

[JKVA]

Janoz schreef op vrijdag 07 september 2007 @ 12:59:
[...]
Database wijzigingen moeten verder gewoon opgenomen worden in de hele release procedure. Ook voor de databases die je de volledige otap straat in te rechten. Zorg verder dat je op alle systemen snel een backup terug kan zetten, dan kun je op test al kijken of het database changescript wel alle verwachte aanpassingen doet. Zorg er daarnaast ook voor dat er regelmatig een (geannonimiseerde en eventueel ingekrompen) versie van productie op de rest uitgerold wordt om alles een beetje synchroon te houden.
[...]

Mja, jammergenoeg zie ik regelmatig, ook bij grotere bedrijven en projecten, dat de database niet netjes in de build wordt meegenomen. Handgemaakte SQL scriptjes circuleren op webdav/sharepoint directories, communicatie over de wijzigingen gebeurt op een vrij ad-hoc basis.

Vanmorgen had ik er weer last van bij mijn huidige klant. Een nieuwe release deployen op 'T' leverde een crash van Hibernate op, omdat een property niet in de DB stond. Na ff navragen bleek het een DB wijziging te zijn waar ik niets van gehoord had. Op 'O' was deze wel doorgevoerd, op 'T' niet.
Gelukkig knalde Hibernate al tijdens het starten van de applicatie, waardoor het vrij vlug gefixed was, maar handig is het niet.

[Janoz]

Mwah, dat is natuurlijk ook een beetje de functie van test. IMHO is het redelijk op tijd naar voren gekomen.

Handgemaakte SQL is overal, maar waarom zitten die niet bij versiebeheer in? Het lijkt me dat dat nu juist hetgeen is dat bij een specifieke branche/versie hoort.

Hmm, of snijd ik hier met versie beheer weer iets nieuws aan....

[kenneth]

Ik vind versiebeheer redelijk essentieel in ontwikkeling, en icm database-ontwikkeling is het inderdaad een achtergebleven gebied ...

[TukkerTweaker]

Verwijderd schreef op vrijdag 07 september 2007 @ 10:38:Kennis van queries opstellen, joins, groeperen, sorteren, indexes, views... critical in je applicatie. Want ook al gebruikt je junior programmeur tools als Hibernate/Toplink e.d. dat maakt het alleen maar makkelijker om verkeerde joins te doen.

Hibernate/Toplink junior programmeur tools?
Wat zijn dan de senior programmeur toools? Beetje onzin i.m.o. Hibernate is in veel gevallen een makkelijk hulpmiddel.

Goed normaliseren is iets wat ik in de praktijk vrij weinig zie. Dit is toch een vak apart en vereist denkwijze dit niet gericht is op ad-hoc ontwikkelen.

[JKVA]

Janoz schreef op vrijdag 07 september 2007 @ 15:20:
Mwah, dat is natuurlijk ook een beetje de functie van test. IMHO is het redelijk op tijd naar voren gekomen.

Handgemaakte SQL is overal, maar waarom zitten die niet bij versiebeheer in? Het lijkt me dat dat nu juist hetgeen is dat bij een specifieke branche/versie hoort.

Hmm, of snijd ik hier met versie beheer weer iets nieuws aan....

Dat is waar. Dit keer wat het ook op tijd, maar het feit dat ik niet op de hoogte was, geeft al aan dat:

• Er geen alles omvattende structuur in de build zit.
• Er wel structuur in zit, maar sommigen om die structuur heenwerken.
• Ik er gewoon niks van snap .

Misschien is het wel gewoon een fact of life dat DB en apps twee verschillende zaken zijn en los van elkaar staan. En dat daar niets mis mee is, zolang we de DB maar als leidend blijven zien en applicaties netjes aanpassen aan alle DB wijzigingen.

Tja, ik denk ook dat het iets is dat je gewoon met versiebeheer moet oplossen. Dan is perfect te traceren welk script waar is gedraaid, door wie en wanneer. Echter, het netjes bijwerken en committen van het script is weer handwerk. En handwerk is waar meestal de problemen ontstaan.

[Knutselsmurf]

Janoz schreef op vrijdag 07 september 2007 @ 12:59:
Wat ik eigenlijk mis is een goede diff tool voor sql scripts. Voor programmacode kun je keurig diff's maken waardoor je simpel kunt upgraden naar een volgende versie. Ik ben nog geen goede tool tegen gekomen die een verschil in create scripts kan omzetten naar een alter table command.

Database wijzigingen moeten verder gewoon opgenomen worden in de hele release procedure. Ook voor de databases die je de volledige otap straat in te rechten. Zorg verder dat je op alle systemen snel een backup terug kan zetten, dan kun je op test al kijken of het database changescript wel alle verwachte aanpassingen doet. Zorg er daarnaast ook voor dat er regelmatig een (geannonimiseerde en eventueel ingekrompen) versie van productie op de rest uitgerold wordt om alles een beetje synchroon te houden.

Zeker in de wat kleinere trajectjes zie je dat de database naast productie, ook nog test en acceptatie is. Soms zie je onderscheid, maar dan is het vaak ontwikkel test en acceptatie op de ene database en productie op de andere. Je hebt dan nergens de ruimte om je upgrade script te kunnen testen.

Ik ken wel tooltjes om twee databases te diffen. Dus niet de create-scripts, maar de databases zelf. Aan de hand hiervan wordt dan een lijst met wijzigingen voorgesteld. Vervolgens kan per wijziging nog worden aangegeven of deze uitgevoerd moet worden.
Hiermee kunnen alle mogelijke soorten wijzigingen ontdekt worden. Het enige waar dit soort tooltjes niet tegen kan, is een naamswijziging van een tabel of een veld. Dit zal gezien worden als een delete van het originele veld en de toevoeging van een nieuwe, zodat de gegevens die in het originele veld stonden verdwenen zullen zijn.

[Janoz]

TukkerTweaker schreef op vrijdag 07 september 2007 @ 15:38:
[...]

Hibernate/Toplink junior programmeur tools?
Wat zijn dan de senior programmeur toools? Beetje onzin i.m.o. Hibernate is in veel gevallen een makkelijk hulpmiddel.

Je leest niet goed. Met de zin worden junior programmeurs bedoeld die tools als hibernate gebruiken. Programmeur was geen bijvoegelijk, maar een zelfstandig naamwoord.

Goed normaliseren is iets wat ik in de praktijk vrij weinig zie. Dit is toch een vak apart en vereist denkwijze dit niet gericht is op ad-hoc ontwikkelen.

Hmmm, ik weet niet op wat voor projecten jij je begeeft, maar over het algemeen zijn de databases die ik op professioneel gebied tegenkom redelijk goed genormaliseerd. En de onderdelen die dat niet zijn zijn vaak met een gegronde reden niet genormaliseerd (of legacy)..

[JKVA]

TukkerTweaker schreef op vrijdag 07 september 2007 @ 15:38:
[...]

Hibernate/Toplink junior programmeur tools?
Wat zijn dan de senior programmeur toools? Beetje onzin i.m.o. Hibernate is in veel gevallen een makkelijk hulpmiddel.

Goed normaliseren is iets wat ik in de praktijk vrij weinig zie. Dit is toch een vak apart en vereist denkwijze dit niet gericht is op ad-hoc ontwikkelen.

Feit is wel dat er tegenwoordig veel ontwikkelaars zijn die middels Hibernate een database kunnen ontsluiten, maar zich vaak niet bewust zijn van performance, N+1 (waar ORM een oorzaak van is), transacties/isolatie, en dergelijke issues. Kort samengevat, het verantwoord gebruik van de database.
Ik denk dat Rebus daar op doelt, dat het met Hibernate voor velen niet duidelijk is wat er op DB niveau gebeurt, met alle negatieve gevolgen van dien.

[Janoz]

@Knutselsmurf: Klopt inderdaad. Er zijn wel tooltjes. Ik heb er een keer eentje mogen gebruiken die op mssql werkte. Deze werkt vergelijkbaar met wat jij aangeeft. We gebruikten deze vervolgens om te kijken of onze change scripts compleet waren.

Probleem is gewoon dat hetgeen ik zou willen eigenlijk gewoon onmogelijk is , maar wees maar gerust. Daar heb ik me al bij neergelegd .

[Acid__Burn]

Ik ben het wel een beetje met de TS eens. Vaak is de database minder belangrijk voor een ontwikkelaar als het werkt. Hij zal niet snel kijken waar hij in de back-end winst kan behalen. Dit mede omdat hij/zij minder kennis heeft van SQL (als het goed is) dan bijvoorbeeld een DBA.

Waar ik wel tegenaan loop binnen het bedrijf waar ik nu werk, is dat er laconiek gedaan wordt over db's en db-servers. Een DBA vinden ze niet nodig, want dat doet systeembeheer er wel bij. Terwijl we toch tussen de 50 en 100 DB's hebben staan.

Een punt dat ik binnenkort wil aankaarten is: "Een DBA naast een ontwikkelaar scheelt tijd". Het scheelt voor de ontwikkelaar tijd omdat hij geen query's e.d. hoeft te maken, en zicht geen zorgen hoeft te maken over de rechten e.d. Hij geeft aan welke data hij wil hebben, en de DBA richt dit zo in. Daarnaast zal de DBA de back-end sneller kunnen maken door inderdaad indexen, views, stored procedures enzovoort te gebruiken. Dus die snelheidswinst kan je optellen bij de Dev tijd.

Ik ben het alleen niet altijd eens met normaliseren. Normaliseren is goed (en niet een tabel met 500 kolommen, die boven de maximale record groote uitkomt die SQL ondersteund) (nee, maar dat is echt zo ) maar je kan ook overnormaliseren. En dat is dan weer funest voor je back-end en je applicatie...

[ Voor 13% gewijzigd door Acid__Burn op 07-09-2007 15:58 ]

[dip]

Acid__Burn schreef op vrijdag 07 september 2007 @ 15:57:
Een punt dat ik binnenkort wil aankaarten is: "Een DBA naast een ontwikkelaar scheelt tijd". Het scheelt voor de ontwikkelaar tijd omdat hij geen query's e.d. hoeft te maken, en zicht geen zorgen hoeft te maken over de rechten e.d. Hij geeft aan welke data hij wil hebben, en de DBA richt dit zo in. Daarnaast zal de DBA de back-end sneller kunnen maken door inderdaad indexen, views, stored procedures enzovoort te gebruiken. Dus die snelheidswinst kan je optellen bij de Dev tijd.

Ik ben het wel met je eens, maar ik vind dit geen goede ontwikkeling. Op deze manier zal de kennis altijd bij de DBA'er blijven liggen. Tevens is het voor een DBA'er (haast) niet mogelijk om te bepalen in welke mate er genormaliseerd dient te worden. Kennis over de context van de applicatie ontbreekt vaak. In veel gevallen kan het efficiënter zijn om sorteringen, caching etc. bijvoorneeld in java te doen ipv op de database.

[JKVA]

Acid__Burn schreef op vrijdag 07 september 2007 @ 15:57:
Ik ben het wel een beetje met de TS eens. Vaak is de database minder belangrijk voor een ontwikkelaar als het werkt. Hij zal niet snel kijken waar hij in de back-end winst kan behalen. Dit mede omdat hij/zij minder kennis heeft van SQL (als het goed is) dan bijvoorbeeld een DBA.

Hmm, toch kom ik vaak DBA-ers tegen met minder kennis dan bijvoorbeeld ikzelf (dat vergelijkt makkelijk). Als fulltime project member ken ik namelijk de context van het project en kan daardoor aardig inschatten wat retesnel moet zijn en wat eventueel trager mag zijn. Dat is van belang bij het leggen van indexen. Sterker nog, dat is zelfs van belang voor je tabellenstructuur.

Daarnaast is niets moeilijker dan queries maken op een database die je niet kent (waarvan je niet weet wat het doel is).

Tevens kom ik regelmatig DBA-ers tegen die geen letter SQL kunnen. Maar goed, ik dwaal af...

Waar ik wel tegenaan loop binnen het bedrijf waar ik nu werk, is dat er laconiek gedaan wordt over db's en db-servers. Een DBA vinden ze niet nodig, want dat doet systeembeheer er wel bij. Terwijl we toch tussen de 50 en 100 DB's hebben staan.

Een punt dat ik binnenkort wil aankaarten is: "Een DBA naast een ontwikkelaar scheelt tijd". Het scheelt voor de ontwikkelaar tijd omdat hij geen query's e.d. hoeft te maken, en zicht geen zorgen hoeft te maken over de rechten e.d. Hij geeft aan welke data hij wil hebben, en de DBA richt dit zo in. Daarnaast zal de DBA de back-end sneller kunnen maken door inderdaad indexen, views, stored procedures enzovoort te gebruiken. Dus die snelheidswinst kan je optellen bij de Dev tijd.

Als de DBA-er echt opgenomen wordt in het projectteam en niet achteraf als specialist erbij wordt gezet, heb je denk ik gelijk ja.

Ik ben het alleen niet altijd eens met normaliseren. Normaliseren is goed (en niet een tabel met 500 kolommen, die boven de maximale record groote uitkomt die SQL ondersteund) (nee, maar dat is echt zo ) maar je kan ook overnormaliseren. En dat is dan weer funest voor je back-end en je applicatie...

Tja, als je tabellen met metadata over je metadata gaat maken ben je iig te ver gegaan.

Maar met dit topic doelde ik vooral op de procesmatige ontwikkeling van databases. Dus niet wanneer en hoe je indexen legt of hoe je normaliseert, maar hoe je op een verantwoorde manier omgaat met veranderingen.

[dip]

JKVA schreef op vrijdag 07 september 2007 @ 16:19:
[...]

Hmm, toch kom ik vaak DBA-ers tegen met minder kennis dan bijvoorbeeld ikzelf (dat vergelijkt makkelijk). Als fulltime project member ken ik namelijk de context van het project en kan daardoor aardig inschatten wat retesnel moet zijn en wat eventueel trager mag zijn. Dat is van belang bij het leggen van indexen. Sterker nog, dat is zelfs van belang voor je tabellenstructuur.

Daarnaast is niets moeilijker dan queries maken op een database die je niet kent (waarvan je niet weet wat het doel is).

Tevens kom ik regelmatig DBA-ers tegen die geen letter SQL kunnen. Maar goed, ik dwaal af...
[...]

So true

[ Voor 62% gewijzigd door dip op 07-09-2007 16:24 ]

[Confusion]

JKVA schreef op donderdag 06 september 2007 @ 18:39:
Bovendien zie ik vaak dat wanneer een applicatie in productie staat, het heel lastig wordt om op een verantwoorde manier wijzigingen door te voeren in de database.

Waarom is dat lastig? Het is toch gewoon een kwestie van 'applicatie down, database updaten, nieuwe applicatie up'?

[Michali]

Ik heb al wel een tijdje dit boek op het oog: Agile Database Techniques. Lijkt me wel interessant om voor dit soort problematiek wat meer informatie te vinden. Misschien kan iemand die dit boek gelezen heeft vertellen of dit boek hier mee te maken heeft?

Ik ondervind zelf wel problemen met het upgraden van de database van een bestaande applicatie naar een nieuwe versie. Ik ben nog op zoek naar een goede manier van werken die de meeste problemen voorkomt.

[Knutselsmurf]

Confusion schreef op vrijdag 07 september 2007 @ 16:34:
[...]

Waarom is dat lastig? Het is toch gewoon een kwestie van 'applicatie down, database updaten, nieuwe applicatie up'?

Het probleem zit hem in de bestaande data. Het toevoegen van een tabel valt nog wel mee. Dan worden de bestaande records aangevuld met de default-waarde. Maar stel dat er in versie 2.0 van de database besloten wordt dan een 1:n-relatie vervangen wordt door een n:m-relatie. Dan wordt het al wat lastiger om de bestaande data in de nieuwe structuur te krijgen. Of er wordt ergens een contraint aan toegevoegd. Wat doe je dan met de bestaande data die niet aan deze contraint voldoet?

[JKVA]

Confusion schreef op vrijdag 07 september 2007 @ 16:34:
[...]

Waarom is dat lastig? Het is toch gewoon een kwestie van 'applicatie down, database updaten, nieuwe applicatie up'?

Technisch stelt het idd niets voor, maar als je niet weet wat de wijzigingen zijn, omdat deze in het project niet op een gestructureerde manier zijn bijgehouden, wordt het een ander verhaal.

En ja, theoretisch mag dat allemaal niet, maar het gebeurt wel. En dat is ook logisch, want het is mensenwerk. Ik zoek nog steeds naar de volledig transparante methode (of tooling).

[Confusion]

Knutselsmurf schreef op vrijdag 07 september 2007 @ 19:24:
Maar stel dat er in versie 2.0 van de database besloten wordt dan een 1:n-relatie vervangen wordt door een n:m-relatie. Dan wordt het al wat lastiger om de bestaande data in de nieuwe structuur te krijgen.

Waarom is dat lastig? IMHO is geen enkele wijziging lastig om technisch door te voeren, mits je de niet-technische kant helder hebt.

Of er wordt ergens een contraint aan toegevoegd. Wat doe je dan met de bestaande data die niet aan deze contraint voldoet?

Dat is een vraag die niet in zijn algemeenheid te beantwoorden is, maar er is altijd een antwoord. Anders slaat de constraint namelijk gewoon nergens op. Op het moment dat je zo'n wijziging door gaat voeren, dan heb je die getest, weet je dus dat die vraag beantwoord moet worden en heb je er een oplossing voor klaarliggen.

JKVA schreef op vrijdag 07 september 2007 @ 19:36:
Technisch stelt het idd niets voor, maar als je niet weet wat de wijzigingen zijn, omdat deze in het project niet op een gestructureerde manier zijn bijgehouden, wordt het een ander verhaal.

In mijn geval: iedereen die database wijzigingen doorgevoerd wil hebben, die stuurt ze naar mij. Bij voorkeur de noodzakelijke queries, desnoods een plaintext beschrijving. Er is maar 1 persoon die aan de live database zit en dat ben ik.

Ik zoek nog steeds naar de volledig transparante methode (of tooling).

Dan zoek je een technische oplossing voor een niet-technisch probleem. Aan onze development database mogen alle developers zitten. Ze mogen wijzigen wat ze willen. Daarom is er no way in hell dat ik die database live ga zetten, al dan niet door eerst een tool diffs te laten trekken. God mag weten wat er allemaal in veranderd is en wat per ongeluk niet goed is gegaan. Ik wil de gewenste diffs, ik zet de oude dev database terug, ik pas de diffs er op toe en test de nieuwe applicatie er tegen. Als dat werkt, dan doe ik hetzelfde op de live server. Het enige dat werkt is een single point of control.

[JKVA]

Confusion schreef op vrijdag 07 september 2007 @ 21:01:
[...]
Dan zoek je een technische oplossing voor een niet-technisch probleem. Aan onze development database mogen alle developers zitten. Ze mogen wijzigen wat ze willen. Daarom is er no way in hell dat ik die database live ga zetten, al dan niet door eerst een tool diffs te laten trekken. God mag weten wat er allemaal in veranderd is en wat per ongeluk niet goed is gegaan. Ik wil de gewenste diffs, ik zet de oude dev database terug, ik pas de diffs er op toe en test de nieuwe applicatie er tegen. Als dat werkt, dan doe ik hetzelfde op de live server. Het enige dat werkt is een single point of control.

Dat is ook goed, behalve dat jij zo in je eentje een potentieel projectrisico bent, omdat je als enige weet hoe het werkt. Jij weet exact welke wijzigingen zijn doorgevoerd, welke trucjes je hebt voor bepaalde specifieke zaken op die database. Misschien ken je wat data (typische klantnummers of ID's) uit je hoofd. Jij bent er immers als enige mee bezig.

De rest weet het niet, waardoor ze een probleem hebben als er een tram over je heenrijdt. (dat wens ik je natuurlijk niet toe, maar je kent het gezegde vast wel )

Role based development is ok, maar heeft grenzen. Bovendien zie ik vaak dat iedereen alles moet kunnen. Als er een productie-incident is, wordt verwacht dat (bijna) iedereen het probleem kan analyseren, oplossen en een release maken + deployen.

[Confusion]

JKVA schreef op vrijdag 07 september 2007 @ 21:45:
Dat is ook goed, behalve dat jij zo in je eentje een potentieel projectrisico bent, omdat je als enige weet hoe het werkt.

De truckfactor van het project is groter dan 1. Dat ik de taak verricht betekent niet dat een ander hem niet kan verrichten; dat ik de database aanpas betekent niet dat ik de enige ben die het databasemodel kent. Ik heb van bepaalde delen van de database nauwelijks kennis; ik voer gewoon de gewenste diffs uit.

Jij weet exact welke wijzigingen zijn doorgevoerd

Het databasemodel staat ook in cvs. De veranderingen zijn traceerbaar en de files met SQL code die worden uitgevoerd per update blijven op de DB server staan en worden in de backup meegenomen. Die kennis zit niet alleen in mijn hoofd.

[JKVA]

Confusion schreef op vrijdag 07 september 2007 @ 23:41:
[...]

De truckfactor van het project is groter dan 1. Dat ik de taak verricht betekent niet dat een ander hem niet kan verrichten; dat ik de database aanpas betekent niet dat ik de enige ben die het databasemodel kent. Ik heb van bepaalde delen van de database nauwelijks kennis; ik voer gewoon de gewenste diffs uit.
[...]

Aha, dan begreep ik je verkeerd. Ik dacht dat jij een DBA rol had en alle beheer van de database voor jezelf hield.

[...]
Het databasemodel staat ook in cvs. De veranderingen zijn traceerbaar en de files met SQL code die worden uitgevoerd per update blijven op de DB server staan en worden in de backup meegenomen. Die kennis zit niet alleen in mijn hoofd.

Ja ok, maar ik denk dat je nog verbaasd zult zijn als iemand anders van de ene op de andere dag jouw taak moet overnemen. Dat valt vaak erg tegen, zelfs voor zeer capabele mensen.

Wat bedoel je trouwens met het op de DB server laten staan van de SQL files? Wat is daar het nut van? Dat je ze direct bij de hand hebt en meteen kunt zien welke veranderingen gedaan zijn? Het klinkt namelijk een beetje dubbelop als je ze ook al in CVS bijhoudt.

[MisterBlue]

Voor wijzigingen op de database vind ik het migration principe zoals het in Ruby on Rails is toegepast wel elegant. De scripts worden opeenvolgend genummerd en hebben allemaal ook een rollback om terug te kunnen gaan naar een vorige status van de database.
In de scripts heb je natuurlijk nog steeds het probleem van hoe je met bestaande data om moet gaan, maar het maakt de simple zaken als het toevoegen van een veld wel triviaal en het is makkelijker voor ontwikkelaars te zien of ze met het laatste schema werken.
Ik ben dit patroon in andere (java) ontwikkelomgevingen echter nog niet tegen gekomen.

Het maakt het makkelijker om op database nivo iteratief te werken. Je kunt je focussen op de wijzigingen die nodig zijn om een user story/functionaliteit te implementeren. En ja, dan let ik heel vaak niet of ik wel of geen index op een veld moet plaatsen. Ik zie dit niet als een probleem. Het is een bewuste keuze omdat ik dan nog te weinig informatie heb over het nut ervan. Ik kan indexen altijd achteraf toevoegen als ik of een echte database specialist met een profiler en logs kan zien op welke plaatsen het wel nut heeft.

[Confusion]

JKVA schreef op zaterdag 08 september 2007 @ 16:08:
Ja ok, maar ik denk dat je nog verbaasd zult zijn als iemand anders van de ene op de andere dag jouw taak moet overnemen. Dat valt vaak erg tegen, zelfs voor zeer capabele mensen.

Er is een ander die de taak af uitvoert als ik het om een of andere reden niet kan. Die kent de procedure. Als een derde de taak onverwacht uit moet voeren, dan zal het inderdaad even lastig zijn. Maar de kans dat tegelijkertijd twee personen uitgeschakeld zijn en er een acute crisis is met betrekking tot de DB, is bijzonder klein.

Wat bedoel je trouwens met het op de DB server laten staan van de SQL files?

Dat was eigenlijk niet zo'n relevante toevoeging. Het voornaamste nut is inderdaad dat je, bij onverwachte problemen, direct kan zijn wat de laatste diff is. Als de problemen na het doorvoeren van die diff begonnen zijn, dan kan dat weleens nuttig zijn.

Het klinkt namelijk een beetje dubbelop als je ze ook al in CVS bijhoudt.

In CVS staat alleen de wekelijkse dump van het databasemodel. Althans: zou moeten, want in de praktijk staat er nu alleen nog een dump als iemand (ik ) die incheckt. Die diffs worden gebackupped met de backup van de database. Is misschien dubbelop (hele database in backup + database model in cvs in backup + diffs in filesystem in backup), maar beter teveel dan te weinig.

[JKVA]

Confusion schreef op zaterdag 08 september 2007 @ 18:55:
[...]
In CVS staat alleen de wekelijkse dump van het databasemodel. Althans: zou moeten, want in de praktijk staat er nu alleen nog een dump als iemand (ik ) die incheckt. Die diffs worden gebackupped met de backup van de database. Is misschien dubbelop (hele database in backup + database model in cvs in backup + diffs in filesystem in backup), maar beter teveel dan te weinig.

Maar ja, "beter te veel dan te weinig" gaat alleen maar op als de verschillende versies in sync zijn. Anders haalt de ene zijn script uit CVS en iemand anders van de DB server backup met als risico dat scripts dubbel (of helemaal niet) gedraaid worden.

[Confusion]

Tjah, als er een perfecte oplossing bestond, dan zou je die ergens kunnen lezen en hier niet de vraag stellen hoe anderen met de database omgaan . Trade offs zal je altijd voor lief moeten nemen.

[JKVA]

Confusion schreef op zondag 09 september 2007 @ 21:06:
Tjah, als er een perfecte oplossing bestond, dan zou je die ergens kunnen lezen en hier niet de vraag stellen hoe anderen met de database omgaan . Trade offs zal je altijd voor lief moeten nemen.

Dat is idd precies wat ik met het topic wil, namelijk zoeken naar de meest ideale oplossing. Dus een oplossing met zo min mogelijk risico's die tegelijk toch weinig (of geen) speciale manuele handelingen vereist. Dat is een utopie, maar we kunnen altijd een poging wagen.

De methode van whoami klinkt als valide, maar ik mis nog het OTAP aspect, dus het bijhouden van de staat van de verschillende servers. (hoe staat het met de Testomgeving? Hoe staat het met de Productieomgeving? Etc) Volgens mij is de meest eenvoudige aanvulling op whoami's methode het toevoegen van notes bovenin de SQL files, eventueel vergezeld door (CVS) commit comments. Het kost weinig moeite, je hoeft geen extra tooling ernaast te introduceren, maar het blijft handwerk. Echter, volgens mij is dat geen groot probleem.

[JKVA]

Gisteren was de kennissessie. Toch wel een aantal interessante dingen gehoord en gezien. Vooral de tools Liquibase en dbdeploy ogen voor mij nuttig.

Rails Migrations lijkt me ook wel cool, maar aangezien ik Java develop en niet een extra taal wil introduceren (Ruby) denk ik niet dat ik het snel zal gebruiken. Bovendien willen klanten waar ik meestal zit (zoals banken) niet dat je applicatie tijdens startup o.i.d. ff de DB bijwerkt. Jammer dat het geen tweetrapsraket is, ofwel DDL uitpoept... Dat had het probleem opgelost.

De presentatie staat hier: http://innoveerjijmee.nl/default.asp/id,308/index.html (helemaal onderaan de pagina)

[MisterBlue]

JKVA schreef op dinsdag 25 september 2007 @ 19:28:

Rails Migrations lijkt me ook wel cool, maar aangezien ik Java develop en niet een extra taal wil introduceren (Ruby) denk ik niet dat ik het snel zal gebruiken. Bovendien willen klanten waar ik meestal zit (zoals banken) niet dat je applicatie tijdens startup o.i.d. ff de DB bijwerkt. Jammer dat het geen tweetrapsraket is, ofwel DDL uitpoept... Dat had het probleem opgelost.

Rails migrations moet je overigens ook expliciet aanroepen en het gebeurd niet automatisch bij startup van de applicatie. Of snap ik niet wat je bedoelt?
Wel leuk te horen dat rails migrations als serieus alternatief is onderzocht.