[SQL] En waarom normaliseer jij niet?

[Janoz]

BikkelZ schreef op dinsdag 29 januari 2008 @ 10:37:
[...]


Als je je hoofdtabel JOINt naar een steuntabel, dan wordt in bijvoorbeeld PHP de id van de hoofdtabel overschreven door die van de steuntabel, als je * gebruikt. Je kunt inderdaad ook alle velden intikken terwijl je eigenlijk * bedoelt, maar dat is ietsjes nadelig voor de performance meen ik.

tja php. Het wordt trouwens niet overschreven. Wanneer je je velden benadert middels de index krijg je gewoon alles eruit. Ikzelf gebruik trouwens sowieso fetch_row.

Het is trouwens eerder * dat nadelig is voor de performance. Niet dat dat überhaupt uit maakt. Als het al verschilt dan is dat zo marginaal. Dat weegt niet op tegen de slecht leesbare code die je met die sterren aan het schrijven bent. Verder kun je met het benoemen van de velden precies aangeven wat je wel en niet nodig hebt. In jou geval bij je bij een join sowieso de gekoppelde id dubbel aan het ophalen.

[BikkelZ]

Janoz schreef op dinsdag 29 januari 2008 @ 11:05:
[...]
tja php. Het wordt trouwens niet overschreven. Wanneer je je velden benadert middels de index krijg je gewoon alles eruit. Ikzelf gebruik trouwens sowieso fetch_row.

Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Voutloos schreef op dinsdag 29 januari 2008 @ 11:04:
[...]
Dat is dan wel het goed argument tegen prefixes dus.

Gnehehehe

[ Voor 19% gewijzigd door BikkelZ op 29-01-2008 11:13 ]

[Janoz]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Nee, ik loop niet te kutten met cijfertjes. Ja, ik fetch met cijfertjes, maar op de regels erboven staat precies een opsomming van de velden incl hun volgorde die vervolgens vlak daar onder middels de setters in het value object worden gezet.

[curry684]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Waarom niet? De query schrijft al voor in welke volgorde je je velden select, dan maakt het in theorie weinig uit of je vervolgens by name of index eraan refereert. De code moet je toch meeveranderen als je de query wijzigt, dus waarom daar geen strakke relatie tussen leggen?

Ik prefereer zelf ook named retrieval via fetch_object, maar dat wil niet zeggen dat het by index minder goed is of zo.

[EfBe]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

list of field names -> projection list of query
en direct ook list of ordinals (middels index) voor field retrieval. Dan 1 row per keer ophalen in array, en middels field - index pairs individuele values ophalen uit array en stoppen in field met naam uit pair. Klaar. Als je maar begint met de lijst met velden voor de fetch, daarna kun je die meteen gebruiken voor value indexing in je row data. Dat is sneller, want je db api hoeft niet telkens naam-> ordinal op te zoeken

[curry684]

EfBe schreef op dinsdag 29 januari 2008 @ 11:25:
[...]

Dat is sneller, want je db api hoeft niet telkens naam-> ordinal op te zoeken

In de praktijk natuurlijk een non-optimalisatie, de gemiddelde computer heeft niet zoveel moeite met string lookups voor een stuk of 10 fields dat het feitelijk enigszins boeit.

[BikkelZ]

Janoz schreef op dinsdag 29 januari 2008 @ 11:16:
[...]

Nee, ik loop niet te kutten met cijfertjes. Ja, ik fetch met cijfertjes, maar op de regels erboven staat precies een opsomming van de velden incl hun volgorde die vervolgens vlak daar onder middels de setters in het value object worden gezet.

Nou ja ik gebruik heel vaak SP's en ik zie gewoon liever direct wat een variabele inhoudt. Dus zelfs als het dan in comments er boven staat geef ik nog de voorkeur aan named.

Maar we dwalen af.....

[Janoz]

Het staat niet in de comments erboven, maar in de query erboven.

[daniëlpunt]

BikkelZ schreef op dinsdag 29 januari 2008 @ 09:39:
Het nadeel is dat item.id en itemcategory.id allebei als id terug komen of de een de ander overschrijft in veel programmeertalen die databases gebruiken. Dus dan kun je niet zeggen SELECT * FROM terwijl je eigenlijk wel alles zou willen hebben uit beide tabellen.

Overigens prefix ik zelf NIET, maar ik twijfel er wel over.

Dit kan toch ook?
SELECT a.*, b.* FROM a, b

[BikkelZ]

super-muffin schreef op dinsdag 29 januari 2008 @ 17:39:
[...]

Dit kan toch ook?
SELECT a.*, b.* FROM a, b

Ja, waarbij in een fetch_assoc a.id overschreven wordt door b.id, terwijl het id van a belangrijk is en niet die van b, want die heb je al in a.b_id.

[curry684]

BikkelZ schreef op dinsdag 29 januari 2008 @ 18:53:
[...]


Ja, waarbij in een fetch_assoc a.id overschreven wordt door b.id, terwijl het id van a belangrijk is en niet die van b, want die heb je al in a.b_id.

Slechts een van de paar honderd redenen waarom ik de schurft heb aan 'id' als wederkerende naam voor PK in iedere tabel van een schema

[EfBe]

curry684 schreef op dinsdag 29 januari 2008 @ 22:22:
[...]

Slechts een van de paar honderd redenen waarom ik de schurft heb aan 'id' als wederkerende naam voor PK in iedere tabel van een schema

Waarom? 'Name' zal ook overal voorkomen, dus je moet dan gaan prefixen met de naam van de tabel, wat ook weer problemen of rariteiten veroorzaakt.

Alleen omdat je meerdere keren 'id' in de projection kunt hebben is het raar? Als je SELECT a.*, b.* FROM ... doet en daar zit 2 keer 'id' tussen en PHP levert dezelfde waarde wanneer je met de string "id" de waarde uit de resultset probeert te halen, ja DUH dat het dan fout gaat... Je moet dan gewoon aliasen, maar dat is met elke dubbele naam zo, niet alleen met 'id'.

[Verwijderd]

BikkelZ schreef op maandag 28 januari 2008 @ 15:39:
...
Ik wil aan de ene kant de achterliggende reden weten waarom duurbetaalde en getrainde professionals tóch voor die - in mijn ogen - inferieure oplossing kiezen, en aan de andere kant kan dit topic misschien ook nog wel als een soort van coming out topic werken
...

Ik heb wel ooit een gedrocht afgeleverd (Toen: Informatica/Universiteit, einde eerste jaar, en ja toen had ik databasnormalisatie en dergelijke al ooit gehad). Toen moest ik een soort van administratiesysteem maken die producten en klanten kon opslaan en die 'uitbreidbaar' is (als in: er zijn data-elementen aan toe te voegen, zoals nieuwe producten, nieuwe producteigenschappen per product), en deze uitbreidbaarheid ZONDER enige vorm van werk (in database, of in code of waar dan ook, gewoon via een pas-de-datastructuur voor dit product-aan-wizard).

Redenen waarom het een niet-genormaliseerd gedrocht was:
- Tijdgebrek
- Voor de verkregen tijd vrij irritante eisen
- Midden in het project toevoegen van nieuwe eisen (zoals: het verwijderen van complete producten en producteigenschappen).
- Ik zou worden bijgestaan door een afgestudeerde professional die mijn ideeen zou bijsturen waar nodig, maar deze vond alles goed en heeft nooit moeite genomen om 'bij te sturen'. Mede omdat de code (PHP) die ik had altijd heel netjes was (Ja ik programmeer wel altijd heel overzichtelijk en net).
- Fixatie op user interface: Ze wouden qua planning vooral snel milestones qua GUI zien, en die direct compleet werkend. Verder gingen ze er van uit dat als ik een werkende GUI had (voor demonstratie) dat ik die dan ook direct compleet werkend kon hebben met achterliggende systemen (dus server-side opslag en zo).

En ik vond het toen al een gedrocht/mislukt ding.

En dat was weer voldoende coming out voor vandaag

[ Voor 11% gewijzigd door Verwijderd op 30-01-2008 10:58 ]

[BikkelZ]

Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:15:
Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

Even alle gekheid op een stokje, jij gaat hier beweren dat het uitnormaliseren van constante waardes een must is? Zodoende kun je ieder attribute wel een aparte tabel gaan geven, maar dat is niet het punt: een m:1 / 1:1 relatie tussen entity E1 en entity E2, waarbij E2 alleen zn identifying attribute A heeft zou je kunnen transformeren naar een situatie waarbij A een attribute van E1 wordt. Dit kan, omdat het lood om oud ijzer is: een FK in E1 voor het identificeren van welk E2 instance bij de E1 instance hoort is gelijk aan het hebben in E1 van het enige attribute van E2 dat er toe doet. Let wel, dit kan omdat A het identifying attribute is van E2 en dus constant.

[Verwijderd]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:15:
Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

Ik hoef me niet op te lucten hoor, ik schaam me er ook niet voor. En verder: Heb daarvoor zat dingen gemaakt die gewoon netjes waren ontworpen en uitgewerkt. Maar goed, voor jezelf werken is toch altijd anders dan werken als loonslaaf. Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 11:39:
[...]

Even alle gekheid op een stokje, jij gaat hier beweren dat het uitnormaliseren van constante waardes een must is? Zodoende kun je ieder attribute wel een aparte tabel gaan geven, maar dat is niet het punt: een m:1 / 1:1 relatie tussen entity E1 en entity E2, waarbij E2 alleen zn identifying attribute A heeft zou je kunnen transformeren naar een situatie waarbij A een attribute van E1 wordt. Dit kan, omdat het lood om oud ijzer is: een FK in E1 voor het identificeren van welk E2 instance bij de E1 instance hoort is gelijk aan het hebben in E1 van het enige attribute van E2 dat er toe doet. Let wel, dit kan omdat A het identifying attribute is van E2 en dus constant.

Maar waar leg je dan de verantwoordelijkheid welke waarde er aan A toegekend wordt? Met een constraint tussen E1.A en E2.A zorg je er voor dat er nooit een waarde van A bestaat dan jij hebt gedefinieerd in E2. Als dat pertinent zeker nooit een zorg zal zijn, omdat een nog niet bestaande waarde van A in E1 niet erg is omdat die dan gewoon toegevoegd mag worden, hoef je die constraint ook niet te leggen.

Om het voorbeeld aan te halen: er mogen geen andere statussen bestaan dan de statussen die we van te voren bepaald hebben. Niemand mag ter plekke bedenken dat er ook nog een status 'doe ik na mijn vakantie' mag komen.

[BikkelZ]

Verwijderd schreef op woensdag 30 januari 2008 @ 11:45:
[...]


Ik hoef me niet op te lucten hoor, ik schaam me er ook niet voor. En verder: Heb daarvoor zat dingen gemaakt die gewoon netjes waren ontworpen en uitgewerkt. Maar goed, voor jezelf werken is toch altijd anders dan werken als loonslaaf. Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

Ik ga nooit echt nadenken over minimale details, ik normaliseer alles gewoon zonder dat ik ga nadenken over waar ik de kantjes er misschien af kan lopen.

[Voutloos]

Verwijderd schreef op woensdag 30 januari 2008 @ 11:45:
Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

Als je dat regelmatig doet, heb je of weinig kosten, of vind je het eten van leger des heils lekker.

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:50:
[...]


Maar waar leg je dan de verantwoordelijkheid welke waarde er aan A toegekend wordt? Met een constraint tussen E1.A en E2.A zorg je er voor dat er nooit een waarde van A bestaat dan jij hebt gedefinieerd in E2. Als dat pertinent zeker nooit een zorg zal zijn, omdat een nog niet bestaande waarde van A in E1 niet erg is omdat die dan gewoon toegevoegd mag worden, hoef je die constraint ook niet te leggen.

Om het voorbeeld aan te halen: er mogen geen andere statussen bestaan dan de statussen die we van te voren bepaald hebben. Niemand mag ter plekke bedenken dat er ook nog een status 'doe ik na mijn vakantie' mag komen.

Op zich een logisch punt, maar een model an sich definieert dat niet. Immers: niets houdt mij tegen om nieuwe E2 instances toe te voegen en zo het arsenaal values voor A uit te breiden. Dus of A nu in E1 of E2 zit, dat doet per saldo niet ter zake. Dat neemt niet weg dat je punt correct is, er moet ergens verantwoordelijkheid liggen welke values voor A legitiem zijn, maar dat ligt buiten het model.

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 12:55:
[...]

Op zich een logisch punt, maar een model an sich definieert dat niet. Immers: niets houdt mij tegen om nieuwe E2 instances toe te voegen en zo het arsenaal values voor A uit te breiden. Dus of A nu in E1 of E2 zit, dat doet per saldo niet ter zake. Dat neemt niet weg dat je punt correct is, er moet ergens verantwoordelijkheid liggen welke values voor A legitiem zijn, maar dat ligt buiten het model.

Klopt, maar het updaten van E2 zou dan natuurlijk niet mogelijk zijn vanuit de stored procedure die het voor de applicatie regelt. Kijk ik denk wel vanuit het principe dat de database zo veel mogelijk zichzelf moet bedruipen, en niet dat de bovenliggende code alles hopelijk een beetje clean houdt. Mensen mogen daar een andere mening over hebben zonder dat ik meteen zeg dat ze het fout doen, zolang er maar een solide gedachtengang achter ligt die uiteindelijk resulteert in kwaliteit (waar ik onderhoudbaarheid ook onder versta).

[ZanomiX]

Sommige mensen normaliseren niet om de kosten gewoonweg te drukken. Als jij een aplicatie moet schrijven voor enkele mensen en je weet van tevoren dat er maximaal 5 records worden ingegeven is het dom om alles tot in de puntjes uit te werken..

[Orphix]

Mijn ervaring is dat bij zeer stabiele waardes, zoals statuscodes, dat het handiger is dit te denormaliseren. Het voordeel is dat alle externe partijen direct naar de status kunnen referen, ipv eerst een lookup doen om vervolgens een numerieke ID mee te geven. Met externe partijen doel ik dan op bv website front-ends (drop-down listjes), webservices, import/export vanuit meerdere databases.

Een statuscode is namelijk globaal uniek voor jouw applicatie, waar een interne ID dat niet is. Het continu vertalen hiertussen neemt complexiteit met zich mee.

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 13:11:
[...]
Klopt, maar het updaten van E2 zou dan natuurlijk niet mogelijk zijn vanuit de stored procedure die het voor de applicatie regelt.

Wat heeft die stored proc ermee te maken? Ik log in via een query tool en update de table. Geen hond die er naar kraait, zeker jouw proc niet.

Kijk ik denk wel vanuit het principe dat de database zo veel mogelijk zichzelf moet bedruipen, en niet dat de bovenliggende code alles hopelijk een beetje clean houdt. Mensen mogen daar een andere mening over hebben zonder dat ik meteen zeg dat ze het fout doen, zolang er maar een solide gedachtengang achter ligt die uiteindelijk resulteert in kwaliteit (waar ik onderhoudbaarheid ook onder versta).

Het punt is dat het model correct moet zijn. HOE het gebruikt wordt, met procs, met vba-string based crap, met php, met een fancy o/r mapper, het boeit niet. Zoals aangegeven: als je de verantwoordelijkheid ergens neerlegt, dus of in een stored proc die ik omzeil, of in een validator in de entity mapped op E2 die je omzeilt met de query tool, het boeit niet, zolang er maar een validator op ligt.

De enige remedie die helpt is de table readonly te maken.

[Verwijderd]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:51:
[...]
Ik ga nooit echt nadenken over minimale details, ik normaliseer alles gewoon zonder dat ik ga nadenken over waar ik de kantjes er misschien af kan lopen.

Ja minimale details is niet alleen database model, maar in het algemeen als ik 'iets' aan het bouwen ben voor mezelf.

Voutloos schreef op woensdag 30 januari 2008 @ 11:51:
[...]
Als je dat regelmatig doet, heb je of weinig kosten, of vind je het eten van leger des heils lekker.

Er is een verschil tussen projectjes die ik voor mezelf doe, en dingen die ik als werk doe .

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 14:22:
[...]

Wat heeft die stored proc ermee te maken? Ik log in via een query tool en update de table. Geen hond die er naar kraait, zeker jouw proc niet.

Het punt is dat het model correct moet zijn. HOE het gebruikt wordt, met procs, met vba-string based crap, met php, met een fancy o/r mapper, het boeit niet. Zoals aangegeven: als je de verantwoordelijkheid ergens neerlegt, dus of in een stored proc die ik omzeil, of in een validator in de entity mapped op E2 die je omzeilt met de query tool, het boeit niet, zolang er maar een validator op ligt.

De enige remedie die helpt is de table readonly te maken.

Inderdaad, dus je geeft je VBA / PHP / PrutsCode 2.23 appje geen root rechten op de database maar alleen indirecte via bijvoorbeeld views en stored procedures. Er is natuurlijk helemaal NIETS wat bestand is tegen de combinatie prutser en root rechten!

Normaliter wil ik al mijn data zowel al correct hebben op applicatieniveau als op databaseniveau, gewoon double safe. Anders krijg je sowieso steeds database errors.

[ Voor 7% gewijzigd door BikkelZ op 31-01-2008 09:32 ]

[Kwistnix]

Ik normaliseer zelf eigenlijk zelden tot nooit meer, omdat ik bijna uitsluitend met ORM oplossingen werk (in mijn geval Hibernate). Hierbij heb je absolute controle over wat er in de database terecht komt, maar fijnmazige controle over hoe het object model naar een relationeel model wordt omgezet heb je minder.
Eigenlijk wil ik helemaal niets van de database / het relationele model afweten, of in ieder geval ik wil er geen omkijken naar hebben.

[BikkelZ]

FallenAngel666 schreef op donderdag 31 januari 2008 @ 10:06:
Ik normaliseer zelf eigenlijk zelden tot nooit meer, omdat ik bijna uitsluitend met ORM oplossingen werk (in mijn geval Hibernate). Hierbij heb je absolute controle over wat er in de database terecht komt, maar fijnmazige controle over hoe het object model naar een relationeel model wordt omgezet heb je minder.
Eigenlijk wil ik helemaal niets van de database / het relationele model afweten, of in ieder geval ik wil er geen omkijken naar hebben.

ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

[Kwistnix]

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]


ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Met Hibernate is dat niet echt een probleem, want je kan in de mapping meta-data expliciet aangeven dat een bepaalde associatie via een join table gemapped moet worden.
Het is wel zo dat je voornamelijk entiteit tabellen krijgt die min of meer 1:1 mappen op de objecten uit het OO model, maar op zich vind ik dat niet echt een nadeel.

[ Voor 11% gewijzigd door Kwistnix op 31-01-2008 10:51 ]

[EfBe]

BikkelZ schreef op donderdag 31 januari 2008 @ 09:30:
[...]
Inderdaad, dus je geeft je VBA / PHP / PrutsCode 2.23 appje geen root rechten op de database maar alleen indirecte via bijvoorbeeld views en stored procedures. Er is natuurlijk helemaal NIETS wat bestand is tegen de combinatie prutser en root rechten!

Dus, jij maakt een proc aan pr_DeleteCustomer, en ik run een app die die proc gebruikt. Ik log in middels een query tool op de DB en aangezien ik pr_DeleteCustomer kan aanroepen, kan ik iedere customer eruit flikkeren die ik wil. Dus procs geven niet MEER security. Je kunt wat jij wilt ook bereiken met roles en rechten per role per table.

Normaliter wil ik al mijn data zowel al correct hebben op applicatieniveau als op databaseniveau, gewoon double safe. Anders krijg je sowieso steeds database errors.

Lijkt me lastig, want er is altijd een tijdstip T te vinden waarbij jouw data inconsistent is in memory.

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]
ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Wat is een 'bijna' 1:1 structuur ? Volgens mij snap jij overigens niet veel van de werken van sets van entities. Ik HOEF helemaal niet de lookup entities op te halen wanneer ik de fk side ophaal, immers dat is puur voor de UI, dat ik lookup tables nodig heb. Die haal je apart op.

[ Voor 25% gewijzigd door EfBe op 31-01-2008 13:23 ]

[BikkelZ]

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]

Dus, jij maakt een proc aan pr_DeleteCustomer, en ik run een app die die proc gebruikt. Ik log in middels een query tool op de DB en aangezien ik pr_DeleteCustomer kan aanroepen, kan ik iedere customer eruit flikkeren die ik wil. Dus procs geven niet MEER security. Je kunt wat jij wilt ook bereiken met roles en rechten per role per table.

Ik vind het prima dat jij mijn klanten weggooit. Wordt de database niet minder consistent van, wel een stuk sneller! Er wordt eerst aangehaald dat je met root rechten direct op de database de consistentie onderuit kan halen, dan moet je natuurlijk niet met dit - geheel losstaande - voorbeeld komen.

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]
Lijkt me lastig, want er is altijd een tijdstip T te vinden waarbij jouw data inconsistent is in memory.

En daarom doe je dus maar helemaal niks?

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]Wat is een 'bijna' 1:1 structuur ? Volgens mij snap jij overigens niet veel van de werken van sets van entities. Ik HOEF helemaal niet de lookup entities op te halen wanneer ik de fk side ophaal, immers dat is puur voor de UI, dat ik lookup tables nodig heb. Die haal je apart op.

Van mij mag je voor jouw GUI best een databaseje volpoepen met wat je maar wil en welke manier je maar wil, zolang ik later maar niks meer te maken krijg met wat je daar in uitvreet en de feitelijke data gewoon netjes genormaliseerd opgeslagen is. Maar waar wil je nou eigenlijk heen met je verhaal, behalve door door op kleine vergezochte puntjes te scoren een 'overwinning' behalen?

[EfBe]

BikkelZ schreef op donderdag 31 januari 2008 @ 13:49:
[...]
Ik vind het prima dat jij mijn klanten weggooit. Wordt de database niet minder consistent van, wel een stuk sneller! Er wordt eerst aangehaald dat je met root rechten direct op de database de consistentie onderuit kan halen, dan moet je natuurlijk niet met dit - geheel losstaande - voorbeeld komen.

Jouw stored procedure voorbeeld heeft ook niets met consistentie te maken. Die beheer je nl. met constraints, niet met DML

[...]
En daarom doe je dus maar helemaal niks?

Dat zeg ik niet, volgens mij... Jij beweert dat je daarnaar streeft. Dat lijkt me wat lastig, dat geef ik alleen aan. Maar goed... whatever.

[...]
Van mij mag je voor jouw GUI best een databaseje volpoepen met wat je maar wil en welke manier je maar wil, zolang ik later maar niks meer te maken krijg met wat je daar in uitvreet en de feitelijke data gewoon netjes genormaliseerd opgeslagen is. Maar waar wil je nou eigenlijk heen met je verhaal, behalve door door op kleine vergezochte puntjes te scoren een 'overwinning' behalen?

Erm... moet ik het voor je spellen of kun je het zelf ook verzinnen hoe het werkt?. Waar ik heen wil met mijn verhaal? Ik reageer alleen op de iewat kortzichtigheid uit jouw hoek.

Triviaal voorbeeld
Een Order entity die een fk heeft naar OrderStatus, dat een lookup is. Een Order entity heeft OrderStatus in-memory niet nodig om valide te zijn, immers je kunt de FK ook vullen met de ID van de OrderStatus.

Als je een order wilt editen, dan haal je de orderstatus entities op, die zet je in een combo box. Dan heb je de Order en de FK OrderStatusID van Order is verbonden met de ID van de selected OrderStatus in de combobox. Met een controller of wat databinding is dat in nauwelijks code voor elkaar te krijgen.

Wat is het probleem dan met O/R mapping, Bikkelz ? Oh, je bedoelde dat je geen graphs kunt fetchen met O/R mappers? Dacht het toch wel. Sterker, efficienter dan jij met je stored procedures:
Haal orders op met filter F + de gerelateerde OrderStatus entities. Dat zijn 2 queries. In stored procs lukt dit niet, want je moet F passen naar de proc voor OrderStatus om alleen de orderstatus entities te fetchen die je nodig hebt voor de orders die je hebt. Aangezien F vanalles kan zijn (joins, filters, etc.) is dit niet generiek op te lossen met procs. (ja je kunt elke graph en elke filter situatie uitschrijven in SQL in een proc. Maar dat wordt wat veel in een grote applicatie)

Ik zou eigenlijk willen zeggen, met O/R mapping heb je juist meer mogelijkheden met deze situatie dan zonder. Ik sneed dit overigens niet aan, dat deed jij. Als jij dan dingen beweert die niet kloppen, mag ik die rechtzetten. Ga dan niet lopen piepen over vergezochte puntjes en overwinningen halen, ik reageer alleen op jouw posts.

[BikkelZ]

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]

Jouw stored procedure voorbeeld heeft ook niets met consistentie te maken. Die beheer je nl. met constraints, niet met DML

Ja, trek het nog ff verder uit verband. Het ging om een vrij bewerkbaar VARCHAR veld. En het heet nog steeds een foreign key constraint.

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]
Triviaal voorbeeld
Een Order entity die een fk heeft naar OrderStatus, dat een lookup is. Een Order entity heeft OrderStatus in-memory niet nodig om valide te zijn, immers je kunt de FK ook vullen met de ID van de OrderStatus.

Yep. Maar een ID is ook zo nietszeggend als je vervolgens weer wilt weten wat die ID inhoudt.

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]

Als je een order wilt editen, dan haal je de orderstatus entities op, die zet je in een combo box. Dan heb je de Order en de FK OrderStatusID van Order is verbonden met de ID van de selected OrderStatus in de combobox. Met een controller of wat databinding is dat in nauwelijks code voor elkaar te krijgen.Wat is het probleem dan met O/R mapping, Bikkelz ? Oh, je bedoelde dat je geen graphs kunt fetchen met O/R mappers? Dacht het toch wel. Sterker, efficienter dan jij met je stored procedures:
Haal orders op met filter F + de gerelateerde OrderStatus entities. Dat zijn 2 queries. In stored procs lukt dit niet, want je moet F passen naar de proc voor OrderStatus om alleen de orderstatus entities te fetchen die je nodig hebt voor de orders die je hebt. Aangezien F vanalles kan zijn (joins, filters, etc.) is dit niet generiek op te lossen met procs. (ja je kunt elke graph en elke filter situatie uitschrijven in SQL in een proc. Maar dat wordt wat veel in een grote applicatie)

Ik zou eigenlijk willen zeggen, met O/R mapping heb je juist meer mogelijkheden met deze situatie dan zonder. Ik sneed dit overigens niet aan, dat deed jij. Als jij dan dingen beweert die niet kloppen, mag ik die rechtzetten. Ga dan niet lopen piepen over vergezochte puntjes en overwinningen halen, ik reageer alleen op jouw posts.

Ik heb nooit gezegd dat SQL de heilige do all fix all oplossing is, maar iedere keer als ik niet gedetailleerd en desalniettemin alsnog uitzondering a vs product b dan toch alles en omgekeerd tot in iedere uitzondering specificeer in mijn betoog kom jij met een hele lap tekst aan waarmee je mij dan de vloer aan wilt vegen, waarin je vervolgens ook de rest van de discussie hier zo veel mogelijk probeert te negeren om ongehinderd exact op die ene fout in te kunnen gaan.

[ Voor 5% gewijzigd door een moderator op 31-01-2008 19:28 ]

[Creepy]

Eeh, doen we het ff rustig aan? Genoeg op de man gespeeld nu dacht ik zo. Onderbouw met argumenten en laat aub de rest achterwege.

[JaQ]

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]
ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Wellicht omdat een objectmodel nou eenmaal geen relationeel model is? Precies de reden waarom ik 90% van de java applicaties die ik tegen kom ronduit kut vind qua RDBMS gebruik. Logica wordt veelal in de applicatie gelegd, terwijl uiteindelijk de data consistent hoort te zijn (en dat doe je dus middels constraints. Of je vervolgens hier stored procedures bovenop legt zal me een zorg zijn, degene die die stored procedure schrijft mag dat ook in een ORM of simpele DML vastleggen.... ).

Uiteraard is mijn mening enorm getekend, ik werk als Oracle DBA

[vorlox]

Kent niemand de term ontnormaliseren, een database guru shiet me misschien af maar m.b.t performance en het uit elkaar kunnen halen van databases. Kun je er SOMS voor kiezen om iets te ontnormaliseren...
Ook kun je denken aan portabiliteit, als je altijd maar met 1 database werkt kun je optimaal gebruik maken van de door de database ondersteunde datatypes (enum, small int enz)
Echter wanneer je een schema maakt voor meerdere databases (Word je hondsdol van) dan moet je zoeken naar de zwakste schakel in de databases die je moet ondersteunen en alles daarop aanpassen. Als je met oracle werkt merkt je dat je b.v. maar max 30 posities voor je tabelnamen / veldlenghtes index lengtes e.d. mag gebruiken. Ook als je dus een enum wilt ondersteunen zul je dus in b.v. oracle gewoon een varchar moeten gebruiken e.d.

Maar goed om idd op je vraag terug te komen, ik ben ook iemand die altijd alles tot op het bot normaliseert. (NOT). Soms is het gewoon goedkoper om het ..smerig te doen vooral als iets een maand ofzo moet werken. Echter bij belangrijke data (Orders, Bestellingen , Artikelen is het raadzaam om het goed op te zetten inclusief constraints)

[ Voor 7% gewijzigd door vorlox op 16-02-2008 00:22 ]

[flowerp]

curry684 schreef op dinsdag 29 januari 2008 @ 11:18:
[...]
Waarom niet? De query schrijft al voor in welke volgorde je je velden select, dan maakt het in theorie weinig uit of je vervolgens by name of index eraan refereert. De code moet je toch meeveranderen als je de query wijzigt, dus waarom daar geen strakke relatie tussen leggen?

Maar de query kan natuurlijk in een apart .sql bestand staan, zodat je in de source code alleen een referentie naar dat bestand ziet, en een JDBC call later een resultset hebt. In dat geval is named lookup natuurlijk erg veel duidelijker.

De query kan daarnaast ook in meerdere plekken in de code gebruikt worden. Als je met indexed lookup werkt, kun je bij veranderingen aan de query moeilijk columns weghalen en zul je voornamelijk columns aan het einde van de lijst toe moeten voegen, wil je niet alle bestaande code breken.

Ik vergelijk het een beetje met classes. Als je iets hebt als:

Java:

public class Record {
  public String foo;
  public String bar;
}

Dan is het duidelijk als je in code record.foo en record.bar gebruikt. Natuurlijk kun je dezelfde data ook modelleren als:

Java:

String[] record = new String[2];

En dan naar de fields verwijzen via record[0] en record[1]. Het -kan-, maar of het ook handig is?

(en natuurlijk is een relationele tabel niet hetzelfde als een Class (anders hadden we geen ORM nodig ), maar het bovenstaande dus even als analogie)

[mphilipp]

momania schreef op maandag 28 januari 2008 @ 16:06:
Klinkt gewoon als: "legacy"

Ehhh...normalisatie is niet iets van de laatste jaren hoor... Dat bestond 20 jaar geleden ook al. Meneer Codd heeft die regels opgesteld terwijl hij de relationele database bedacht.

Het is gewoon luiheid/onbenulligheid. Ik heb de afgelopen 20 jaar zoveel eikels meegemaakt die klakkeloos maken wat een of andere knurft heeft bedacht. Ook al klopt dat van geen meter. Ik doe zoiets niet. Nooit gedaan ook. Ook niet als junior. Als ik ergens mijn vraagtekens bij heb, zeg ik dat en wijs ze op de mogelijke nadelen. Als het écht iets vreselijks is, zorg ik dat het ergens op papier komt oid want naderhand heb ik het natuurlijk gedaan.

Punt is dat iedereen die dergelijke dingen (bewust) fout doet, denkt dat het geen kwaad kan. Dat is dan een gebrek aan visie denk ik. Zo iemand kan zich niet voorstellen dat een systeem waarschijnlijk nog wat jaartjes mee moet. Of ze geloven werkelijk dat de klant precies weet wat ie ooit gaat willen. Want vaak is dat ook het probleem: men roept dat iets tijdelijk is of dat men nooit aan de functionele eisen van het systeem zal gaan tornen. En binnen 6 maanden is het meestal toch zover. En dan zitten ze met een datamodel dat een bepaalde structuur niet meer toestaat zonder een ingewikkelde conversie.

Een van de redenen waarom ik (nu dan eindelijk succesvol) uit het ontwikkelwerk ben gestapt. Kostte wat tijd, maar het is dan gelukt. Baalde ervan om aan krakkemikkige systemen te werken op projecten die gedoemd zijn...

[PainkillA]

is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan? Als ik ergens een hekel aan heb is het wel een te krappe tijd voor toch soms wel complexe systemen waardoor je het maar op de "snel af maar bagger" manier meot doen.

[flowerp]

PainkillA schreef op zondag 17 februari 2008 @ 16:32:
is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan?

Het is ook dikwijls onkunde van het personeel. Jongetjes van 18 die PHP/MySQL op hun CV zetten en die door een baas worden ingehuurd die het verschil niet snapt tussen de kunde van een scriptkiddie en iemand die minstens 4 jaar studie achter de keuzen heeft en enkele jaren ervaring.

Natuurlijk hebben deze jochies de ballen verstand niet van normalisatie en correcte naamgevingen. Logisch, want in de regel kopiëren ze slechts scriptjes van PHPFreakz. "Naamgeving? Waarom zou ik daar over nadenken, in scripts staan toch al namen??? :?"

Op de een of andere manier blijven dergelijke 'ontwerpen' toch langer in gebruik en mag jij als iemand die wel een beetje weet hoe dingen werken er later uitbreidingen op maken.

[LauPro]

Dat alles valt weer terug te voeren op budget. ICT is voor de meeste bedrijven al duur genoeg (zeker in MKB), dus geen wonder dat men aan alle kanten wil besparen. Natuurlijk kan je voor 150 euro de uur iemand met 10 jaar ervaring neerzetten op een project, maar misschien bereik je wel evenveel met iemand die maar 25 euro per uur kost en die er dan 4 keer langer over doet.

Daarnaast richten de bedrijven die echt de kennis in huis hebben zich meestal niet op die bedrijven. Hoe dan ook, vroeg of laat zal de kennis van een expert nodig zijn dus ik zie het niet als een gevaar voor de sector.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 99% gewijzigd door Ruudjah op 02-12-2009 00:23 ]

[LauPro]

Ruudjah schreef op zondag 17 februari 2008 @ 23:38:
Ja, precies. Het is alleen jammer dat ze niet inzien dat een developer van 150 in het uur wel een systeem kan bouwen wat efficient, onderhoudbaar, duidelijk, goed ontworpen etc etc etc is. Die iemand van 25 euro in het uur krijgt misschien ook wel een systeem af, maar kwa kwaliteit veel minder.

Het staat nog niet vast of iemand met 10 jaar ervaring per definitie een betere kwaliteit kan leveren. Doorgaans zal dat zeker zijn maar er zijn ook mensen bij die in een totaal eigen wereld leven en techniek van 10 jaar geleden toepassen.

Het punt is dat bedrijven niet inzien dat goedkoop duurkoop is.

Voor een simpel signupformulier is een uitgebreide analyse helemaal niet nodig. Daarnaast wil en kan men aan het begin van een traject niet altijd de hoofdprijs betalen.

Ontopic: Ik denk dat opleidingen veel te weinig aandacht besteden aan documenteren, specificeren en benamen van entiteiten, klassen en dergelijke. Hongaarse notatie?

Het probleem zit hem niet in de opleidingen maar in de industrie die razendsnel verandert. Ook qua documentatiemethodes, alles. Je moet als moderne developer eigenlijk in een metataal kunnen schrijven, terwijl je vroeger gewoon echt enkel en alleen COBOL zou doen. En dingen als Hongaarse notatie: veel mensen beschouwen dat als een aftandse legacy van C, daar zijn ook modernere varianten voor (of bijvoorbeeld een editor die dmv colorcoding variabletypes weergeeft).

[EfBe]

(en natuurlijk is een relationele tabel niet hetzelfde als een Class (anders hadden we geen ORM nodig ), maar het bovenstaande dus even als analogie)

Een class definitie 'Customer' en een tabeldefinitie 'Customer' representeren wel degelijk hetzelfde. Als ze dat niet doen, dan zit je in je applicatie met 2 verschillende abstracte entity definities te werken. Lijkt me het begin van het einde.

PainkillA schreef op zondag 17 februari 2008 @ 16:32:
is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan? Als ik ergens een hekel aan heb is het wel een te krappe tijd voor toch soms wel complexe systemen waardoor je het maar op de "snel af maar bagger" manier meot doen.

Nee, de meeste mensen die werken aan software zijn gewoon niet goed genoeg voor hun vak. Iemand die hello world kan schrijven in C# is nog geen software engineer die weet van de basisbegrippen van de informatica... Net zoals iemand die geprogrammeerd heeft op zn afstudeeropdracht voor werktuigbouw geen software engineer is bv. Die mensen op een project zetten waar basisbegrippen essentieel zijn (en dat is vrijwel altijd zo) dan heb je een probleem, of als je geluk hebt gaat het net goed.

Het is niet alleen de kunde (of beter: het gebrek eraan) van veel mensen overigens hoor. Veelal gaat het project mis door politieke spelletjes van managers, geld en daardoor brakke planningen.

LauPro schreef op zondag 17 februari 2008 @ 23:48:
[...]
Het staat nog niet vast of iemand met 10 jaar ervaring per definitie een betere kwaliteit kan leveren. Doorgaans zal dat zeker zijn maar er zijn ook mensen bij die in een totaal eigen wereld leven en techniek van 10 jaar geleden toepassen.

Als jij denkt dat techniek belangrijk is voor goede software snap je niets van informatica. Iets wat 10 jaar geleden waar was in computer science, is dat tegenwoordig nog steeds. Talen/tools veranderen wellicht, basisbegrippen en daarop gefundeerde solide wijsheden niet.

Het punt is juist dat mensen die 10-15 jaar ervaring hebben niet meer software bouwen. Die worden projectleider of manager. Het werk wordt gedaan door mensen die erg weinig ervaring hebben en omdat er in nederland maar een handjevol informatici per jaar afstudeert, is het gros van wat code zit te tikken self-made specialist.

[...]
Het probleem zit hem niet in de opleidingen maar in de industrie die razendsnel verandert. Ook qua documentatiemethodes, alles. Je moet als moderne developer eigenlijk in een metataal kunnen schrijven, terwijl je vroeger gewoon echt enkel en alleen COBOL zou doen. En dingen als Hongaarse notatie: veel mensen beschouwen dat als een aftandse legacy van C, daar zijn ook modernere varianten voor (of bijvoorbeeld een editor die dmv colorcoding variabletypes weergeeft).

hungarian notation heeft niets met informatica te maken en is daarom irrelevant. Het is wellicht een leuk voorbeeld voor de wat softere vakken tijdens een studie om aan te geven dat goed samen kunnen werken essentieel is voor het eindresultaat in een team, maar voor de rest voegt kennis daarvan niets toe.

Ik snap verder jouw opmerking over dat de industrie razendsnel verandert niet. Basisbegrippen uit de informatica zijn dingen die veranderen niet doordat MS een nieuwe versie van .NET uitbrengt of dat we nu, doordat een marketeer dat roept, met zn allen silverlight of flash/flex/whatever dingen moeten gaan bouwen.

Basisbegrippen aanleren tijdens een studie, zodat je niet gedwongen wordt hoeken af te snijden ivm deadlines/projectgrenzen, is essentieel. DAARNA doe je dat nl. niet meer. Het nadeel is echter dat je WEL die basisbegrippen nodig hebt voor je verdere werk.

Ik vind het bv tenenkrommend dat veel mensen die met hun handen aan databases zitten helemaal niet snappen wat een 'entity' eigenlijk inhoudt, wat NIAM is etc. Als je vanuit de hobbysfeer bezig bent met databases en denkt in tabellen... soit. Maar als professional vind ik het, sorry, een doodzonde als men niet dat soort basisbegrippen snapt. Ik verwacht van een professional dat hij/zij zn vak verstaat. Dat verwacht men nl. van mij ook, dus waarom kan ik dat niet van mede-vakgenoten verlangen? Of bestaat er zoiets als een semi-professional in ons vakgebied, die wel het volle pond vraagt en krijgt, maar het werk aflevert van een amateur met 2 weken ms access ervaring?

[ Voor 106% gewijzigd door EfBe op 18-02-2008 09:37 ]

[BikkelZ]

Ruudjah schreef op zondag 17 februari 2008 @ 23:38:Ontopic: Ik denk dat opleidingen veel te weinig aandacht besteden aan documenteren, specificeren en benamen van entiteiten, klassen en dergelijke. Hongaarse notatie? 95% die uit een HBO informatica opleiding komt heeft geen idee waar je het over hebt. Normaliseren? Wel geleerd, maar half weggezakt. Correct OO design? Toch gewoon alle tabellen als klassen implementeren? Als opleidingen erop zouden hameren dat naamgeving, OO ontwerp, normaliseren en documenteren de belangrijkste dingen zijn die je moet kunnen dromen, die erin gestampt moeten zitten, die je bij wijze van spreken direct als je wakker word moet kunnen opdreunen, dan zouden dit soort dingen VT zijn. Je haalt het dan niet meer in je hoofd om ff een variabele 'temp' te noemen. Of hongaarse notatie toepassen op .NET code. Of toch stiekum eventjes die enumeratie als string normaliseren. Of weigeren OO principes toe te passen.

Ondanks dat ik enorm op het Fontys afgegeven heb, is dit wel een regelmatig terugkomend onderdeel geweest van mijn studie. Dat doen ze ook wel. En Hongaarse notatie: waarom moet er legacy onderwezen worden?

[LauPro]

EfBe schreef op maandag 18 februari 2008 @ 09:14:
Een class definitie 'Customer' en een tabeldefinitie 'Customer' representeren wel degelijk hetzelfde. Als ze dat niet doen, dan zit je in je applicatie met 2 verschillende abstracte entity definities te werken. Lijkt me het begin van het einde.

Ben met je eens dat dat het geval zou moeten zijn, in de praktijk zullen echter veel systemen zijn waar dit niet het geval is. Genoeg kansen dus nog .

Als jij denkt dat techniek belangrijk is voor goede software snap je niets van informatica. Iets wat 10 jaar geleden waar was in computer science, is dat tegenwoordig nog steeds. Talen/tools veranderen wellicht, basisbegrippen en daarop gefundeerde solide wijsheden niet.

Techniek gedoel ik generiek zowel qua organisatie alswel implementatie. Om maar een voorbeeld te nemen aan Agile development, een nog jonge methode die de afgelopen 10 jaar zich zeker heeft bewezen. Door de verandering van techniek veranderen ook basisbegrippen. Vroeger hadden we de gecentraliseerde execution domains, dat is daarna uitgesplitst naar de fat clients. De laatste tijd zie je een omdraaid effect dat bedrijven weer gaan standaardiseren op gecentraliseerde execution domains. Dit heeft ook veel impact op de gebruikte software en technieken, daar waar software op de fat client wordt geoptimaliseerd voor single user worden gecentraliseerde systemen (weer) multiuser met alle implicaties van dien.

Het punt is juist dat mensen die 10-15 jaar ervaring hebben niet meer software bouwen. Die worden projectleider of manager. Het werk wordt gedaan door mensen die erg weinig ervaring hebben en omdat er in nederland maar een handjevol informatici per jaar afstudeert, is het gros van wat code zit te tikken self-made specialist.

Er zijn ook echt wel mensen die 10-15 jaar ervaring hebben en geen manager zijn, dit bedoel ik niet negatief maar er lopen natuurlijk niet alleen maar managers rond. En nogmaals vind ik dat je hier de vraag moet stellen of je altijd een afgestudeerd iemand moet hebben voor de job. Vergelijk het met het schildersdiplomap. Er zijn zat mensen die hun huis zelf verfen zonder diploma, dat kan voor waardevermindering zorgen. Moet je dan maar verplichten dat je dat altijd aan een gediplomeerd schilder over moet laten?

Het is een vrije markt, zowel particulieren alswel bedrijven kunnen zelf kiezen waar ze hun werk uitbesteden.

hungarian notation heeft niets met informatica te maken en is daarom irrelevant. Het is wellicht een leuk voorbeeld voor de wat softere vakken tijdens een studie om aan te geven dat goed samen kunnen werken essentieel is voor het eindresultaat in een team, maar voor de rest voegt kennis daarvan niets toe.

Dit vind ik een beetje overtrokken, je moet gewoon verstand van zaken hebben en kunnen leren uit de lessen uit het verleden. De HN is wat dat betreft een mooi voorbeeld van een eigenschap van decentralised working. Het principe achter deze stelregel gaat nog steeds op, de implementatie is echter verouderd.

Ik snap verder jouw opmerking over dat de industrie razendsnel verandert niet. Basisbegrippen uit de informatica zijn dingen die veranderen niet doordat MS een nieuwe versie van .NET uitbrengt of dat we nu, doordat een marketeer dat roept, met zn allen silverlight of flash/flex/whatever dingen moeten gaan bouwen.

De meeste HBO opleidingen zijn vooral gericht op de praktijk. Dus in zoverre hebben veranderingen in de industrie wel direct impact op de recentheid van deze opleidingen. Bij WO opleidingen heb je op zich gelijk als je zegt dat er meer op een abstracter niveau wordt gekeken, maar ook dan kan iemand volledig verdwalen als hij wel de kaders weet maar de taal spreekwoordelijk niet spreekt.

Basisbegrippen aanleren tijdens een studie, zodat je niet gedwongen wordt hoeken af te snijden ivm deadlines/projectgrenzen, is essentieel. DAARNA doe je dat nl. niet meer. Het nadeel is echter dat je WEL die basisbegrippen nodig hebt voor je verdere werk.

Dit ligt natuurlijk geheel aan je positie en verantwoordelijkheden. Vanaf een software developer gezien moet je die eigenschappen hebben, al hoewel veel bedrijven hier een leerproces acceptabel vinden. Het is voor die bedrijven ook niet altijd in te schatten wat marktconform is en waar de top ligt.

Of bestaat er zoiets als een semi-professional in ons vakgebied, die wel het volle pond vraagt en krijgt, maar het werk aflevert van een amateur met 2 weken ms access ervaring?

Ja, die bestaan. Ik heb het helaas zelf meegemaakt pas. Maar er zijn ook nog gerenommeerde bedrijven die voor applicaties Access gebruiken. En als je daar opmerkingen over gaat maken krijg je een recalcitrante projectleider over je heen die zijn kindje gaat verdedigen wat uiteindelijk je eigen reputatie alleen maar schaadt.

Ik zou zelf nooit geld durven vragen voor werkzaamheden aan een Access database. En mocht ik ooit voor die keuze komen te staan dan zou ik toch proberen om zo'n opdracht om te vormen in een migratieproject. Er zijn echter zat mensen die niet zo principieel zijn en (hun goed recht) gewoon werkzaamheden uitvoeren als de klant daarvoor wil betalen. Hoe zwartmakend en derigerend dat ook kan zijn.

[flowerp]

EfBe schreef op maandag 18 februari 2008 @ 09:14:
Een class definitie 'Customer' en een tabeldefinitie 'Customer' representeren wel degelijk hetzelfde. Als ze dat niet doen, dan zit je in je applicatie met 2 verschillende abstracte entity definities te werken. Lijkt me het begin van het einde.

Inderdaad, natuurlijk -representeren- ze het zelfde in dat geval

Technisch gezien zijn een class en een tabel definitie wel verschillend (anders zou een class dus gewoon 1:1 in de DB gestopt kunnen worden zonder enige vorm van mapping). De opmerking was echter niet zo diepgravend bedoeld. Gewoon om me zelf een beetje in te dekken daar ik verwachte dat er wel weer reacties zouden komen in de trend van: "Hey, das appels met peren vergelijken, een class is niet hetzelfde als een tabel dus je vergelijking slaat nergens op".

Nee, de meeste mensen die werken aan software zijn gewoon niet goed genoeg voor hun vak.

Amen!

Als dat nu eens algemeen geaccepteerd zou gaan worden. In de advocatuur heb je toch ook duidelijk top advocaten en gewone advocaten. In b.v. de sporters wereld geldt dat nog sterker. Ontwikkelaars moeten echter altijd maar allemaal gelijk zijn aan elkaar. Hooguit wordt iemand senior genoemd op basis van hoe lang die persoon bij een bedrijf in dienst is (wat onzin is, maar de meeste bedrijven die ik ken hebben gewoon amper maatstaven om te meten hoe goed iemand nu is of niet).

[ Voor 25% gewijzigd door flowerp op 18-02-2008 20:39 ]

[EfBe]

flowerp schreef op maandag 18 februari 2008 @ 20:34:
[...]
Amen!
Als dat nu eens algemeen geaccepteerd zou gaan worden. In de advocatuur heb je toch ook duidelijk top advocaten en gewone advocaten. In b.v. de sporters wereld geldt dat nog sterker. Ontwikkelaars moeten echter altijd maar allemaal gelijk zijn aan elkaar. Hooguit wordt iemand senior genoemd op basis van hoe lang die persoon bij een bedrijf in dienst is (wat onzin is, maar de meeste bedrijven die ik ken hebben gewoon amper maatstaven om te meten hoe goed iemand nu is of niet).

Het is gewoon een geldkwestie, veelal worden trainees 'weggezet' bij klanten voor een vol tarief, worden mensen met 2 jaar knutselervaring in office VBA als senior software engineers naar klanten gestuurd, puur omdat die titels meer geld opbrengen.

Het stoort mij ook mateloos. Maar er is weinig tegen te doen ben ik bang: er zijn gewoon veel te weinig mensen met voldoende kennis. En dus worden de mensen die wat cursussen hebben gevolgd al gauw voor specialist aangezien, omdat er niemand anders is en de problemen bij 'de klant' moeten wel worden opgelost.

Een aantal jaren al is er een exponent bijgekomen: de architect. 10 jaar geleden was de oppermufti van de software jongens van een bedrijf de 'senior', nu is dat de 'architect'. Het vervelende is dat veel architecten niet zelf software bouwen, en wel allerlei leuke dingen bedenken, maar de haalbaarheid ervan niet snappen noch kunnen inzien.

Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

[BikkelZ]

Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

[EfBe]

BikkelZ schreef op dinsdag 19 februari 2008 @ 10:05:
Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

Tja, geen idee. Een manager verdient meer dan iemand die de software daadwerkelijk bouwt, en dat komt mogelijkerwijs omdat de manager wellicht ouder is, vroeger de programmeur was etc. en de bouwer 2 jaar ervaring heeft en net 25 is.

Als je als persoon met hart voor het vak je werk echt goed wilt doen dan is daar niet echt veel waardering voor bij management, wanneer dat meer tijd kost. Er is een of andere blindheid geslopen in het gros van de managers die het onmogelijk voor hen maakt om in te zien dat kwaliteit op den duur loont. Op de langere termijn hebben wij als maatschappij er alleen maar baat bij. Maar hoe het nu gaat, vrees ik het ergste, temeer omdat we steeds meer afhankelijk worden van software maar de niet-nerds niet inzien dat die afhankelijkheid wel een nadeel heeft: zonder nerds gaat alles fout.

het is echt heel weinig wat van de universiteiten en hbo's afkomt. Dat is al een tijdje zo trouwens. In 1994, toen ik van de HIO enschede afkwam, waren we met zn 40en die afstudeerden. In datzelfde jaar begonnen er 38 nieuwe studenten als ik het goed heb. Aangezien er nogal wat mensen afvallen gedurende de studie kun je wel uitrekenen hoe weinig er afkwamen in 1998-99.

Overigens ben ik van mening dat de echte specialisten wel degelijk veel geld krijgen betaalt. Het is alleen zo dat je als specialist niet voor uurtjefactuurtje excelprutjes moet gaan zitten krassen bij CMG, maar bij een softwarehuis de hoofdontwikkelaar moet worden. Iemand die echt goed is verdient zn/haar geld echt wel terug: het werk komt af, van hoge kwaliteit, onderhoudbaar etc. maar men is daar heel vaak niet in geinteresseerd: als de klant maar tevreden is (ookal weet de klant niet wat beter was geweest) of erger: als de klant de rekening maar betaalt. Ik bedoel: de belastingdienst jaagt er per jaar 400 miljoen euro (!) doorheen met 4200 (!) IT medewerkers.Daar werken vele externen. Elk jaar gaat het slechter met de software daar. Totdat iemand echt paal en perk gaat stellen aan dat soort zaken (die overal spelen, niet alleen bij de belanstingdienst), is het echt heel lastig dat nog op te lossen, temeer daar over 10 jaar de hoeveelheid software die onderhouden moet worden veel groter is dan nu, maar de hoeveelheid mensen die dat kan niet echt veel groter.

[Hydra]

Verwijderd schreef op maandag 28 januari 2008 @ 23:52:
Sorry hoor, ik weet niet precies wat voor beeld jij hebt van het HBO, of op welke school jij HBO-I hebt gedaan, maar ik ben nu bezig op de Fontys en ben op software engineering en database gebied best tevreden tot nu toe (helft 1e jaar).

Ik heb een jaar of 8 geleden een meisje dat aan de Fontys studeerde moeten helpen met haar Java opdrachten omdat de docenten er zelf ook niet uitkwamen, dus breek me de bek niet open over de Fontys. Ik heb zelf HBO-I gedaan aan Saxion Enschede (toen nog HIO), en die opleiding zijn ze ook compleet aan het uithollen. We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

EfBe schreef op dinsdag 19 februari 2008 @ 09:42:
Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

Oh, Nederland gaat een groot probleem krijgen als het om capabele ITers gaat. Ik ben onlangs naar Saxion geweest om weer eens een praatje te maken en te informeren over hoe we nu aan stagairs moeten komen, en dat gaat een groot probleem worden. Voor elke HBO-I-er zijn er 10 opdrachten, en de instroom wordt alleen maar lager terwijl de uitval ongeveer gelijk blijft. Dit hebben we allemaal aan onze overheid te danken, we zien nu de gevolgen van het falende beleid m.b.t. onderwijs.

BikkelZ schreef op dinsdag 19 februari 2008 @ 10:05:
Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

Omdat mensen nog niet doorhebben hoe schaars goeie developers aan het worden zijn. Moet je eens kijken wat je in de VS kunt verdienen t.o.v. hier.

[BikkelZ]

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
[...]
Ik heb een jaar of 8 geleden een meisje dat aan de Fontys studeerde moeten helpen met haar Java opdrachten omdat de docenten er zelf ook niet uitkwamen, dus breek me de bek niet open over de Fontys. Ik heb zelf HBO-I gedaan aan Saxion Enschede (toen nog HIO), en die opleiding zijn ze ook compleet aan het uithollen. We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

Je hebt natuurlijk Fontys, Fontys, Fontys en Fontys hè. Maar ik moet zeggen dat het me inderdaad wel opviel hoe je gematst wordt om toch je diploma te halen. Op zich op een enkeling na heb ik niet echt docenten meegemaakt die beter wat anders konden gaan doen.

[LauPro]

EfBe schreef op dinsdag 19 februari 2008 @ 09:42:
Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

Wil dat niet gewoon zeggen dat je als automatiseerder gewoon flexibeler op moet gaan stellen? Het is bijna altijd lonender en uitdagender om bij grote projecten veel zelf te ontwikkelen. Bedrijven kijken gewoon heel simpel hoeveel productie iemand kan behalen en wat hij daarbij op kan leveren. Daar worden echt geen grotere verhalen omheen gehangen dan jij nu doet voordoen.

Bovendien ontgaat me de insteek van het 'maatschappelijk nut' een beetje. Als je wil dat de kwaliteit van het onderwijs beter gaat worden had men toch echt 20 jaar geleden al moeten beginnen. Nu is het gewoon te laat, einde verhaal. Zeker wel belangrijk om voor de toekomst er weer in te investeren maar verwacht op korte termijn geen resultaat.

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
Omdat mensen nog niet doorhebben hoe schaars goeie developers aan het worden zijn. Moet je eens kijken wat je in de VS kunt verdienen t.o.v. hier.

Dit is gewoon BS, onvergelijkbaar en totaal offtopic. Het complete arbeidsklimaat is in de VS anders.

[Verwijderd]

We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

Dat is een ontwikkeling die, spijtig genoeg, niet alleen tot informatica beperkt blijft. Scholen passen het niveau aan naar het niveau van de studenten. Dus, de eisen gaan omlaag, het niveau gaat omlaag, zodat de cijfers een beetje gehandhaaft blijven.

Concreet voorbeeld: ik zit nu in mijn afstuderen, maar omdat er bepaalde vakken weg zijn gevallen hebben ze als vulling de vakken SOTA en ABV09 in het leven geroepen, de eerste is op zich nog redelijk interessant, namelijk het bijwonen van lezingen die op school gegeven worden, maar de tweede houdt in dat we een zelfstandig ondernemer moeten gaan interviewen

Wat bereiken ze er mee: het aantal ECTS wat een student nodig heeft voor zijn diploma. Je kan me niet wijsmaken dat dergelijke nonsense ook maar iets aan praktisch nut heeft.

Theoretische diepgang hebben ze uberhaupt nog nooit van gehoord, de Java vakken in het eerste jaar Volgens het curriculum kwam object oriëntatie pas aan bod aan het eind van jaar 1. Dat is op zich niet zo erg, mits er goede lessen worden gegeven over het hoe en wat van algoritmiek e.d., maar dat was natuurlijk niet het geval, veel verder dan een array of system.out.println() zijn we niet gekomen. En nóg vallen er mensen af met als gevolg dat de stof nóg minder diepgang krijgt, zodat er minder mensen afvallen.

Ander voorbeeld, wiskunde, de bedoeling: complexe getallen, integralen, partiële integralen, differentiëren en lineaire algebra
Uitwerking: basis goniometrie. (SOS-CAS-TOA ), met hier en daar een inverse en 3de graads polynoom. Daarnaast nog een vak lineaire algebra.
Reden? Teveel moeite met wiskunde, dus curriculum aangepast op het niveau van de studenten, met als gevolg dat meer mensen het halen, met als gevolg dat het diploma weer een stukje minder waard is geworden.

Minor project, 30ECTS, woensdagmiddag terugkoppeling. Bedoeling: bedenk, ontwerp en implementeer een 3dgame in een geschikte taal. Bewijs dat je een X-aantal competenties hebt. Prima, maar je zou verwachten dat je tijdens een minor software engineering vakken krijgt over het onderwerp. Neen. Een docent waarvan ik de kunde twijfelachtig zou willen noemen en een andere die niet eens kán programmeren

Afstuderen, 5 dagen in de week? Nee, we hebben verzonnen dat we die laatste dag gaan verpakken in het zogenaamde 'leerwerkbedrijf', daar haal je 6 ECTS mee, dus hoef je nog maar 4 dagen in de week af te studeren. Kun je nog lekker op school ABV vakken gaan zitten, tijdens je afstuderen. PRIMA regeling, logisch ook, afstuderen is nog niet druk genoeg, natuurlijk.

^{Hmmmm, enigszins off-topic gal spuwen}

[kamerplant]

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
[...]


Oh, Nederland gaat een groot probleem krijgen als het om capabele ITers gaat. Ik ben onlangs naar Saxion geweest om weer eens een praatje te maken en te informeren over hoe we nu aan stagairs moeten komen, en dat gaat een groot probleem worden. Voor elke HBO-I-er zijn er 10 opdrachten, en de instroom wordt alleen maar lager terwijl de uitval ongeveer gelijk blijft. Dit hebben we allemaal aan onze overheid te danken, we zien nu de gevolgen van het falende beleid m.b.t. onderwijs.

Kun je het concreter maken? Wat zou de overheid moeten doen om de kwaliteit van afgestudeerde studenten te verhogen?

Als ik even naar mijn eigen opleiding kijk (HBO-BI), dan zie ik dat de opleiding prima is. Wat ik ook zie is dat een grote groep studenten net voldoende motivatie heeft om alles met een 6je af te ronden. Toetsen worden nauwelijks geleerd zodat na 3 kansen het eindelijk eens wordt gehaald omdat een toets uitlekt. Er zijn ook genoeg studenten die hier niet aan meedoen en zodoende wel genoeg opsteken van de opleiding. (true, ik breng het een beetje zwart-wit)
Om nu zomaar de schuld heel gemakkelijk bij "de overheid" te leggen, mwahh. Studenten zelf hebben ook een behoorlijk verantwoordelijkheid voor hun eigen leerproces. Neem normaliseren, dat wordt écht wel in een HBO-I opleiding gegeven hoor

[Gé Brander]

Ja, en die 6je studenten weten net aan hoe je het moet schrijven (normaliseren) en weten dat het iets met database structuren te maken heeft.

[curry684]

Datafeest schreef op dinsdag 15 juli 2008 @ 10:55:
[...]


Kun je het concreter maken? Wat zou de overheid moeten doen om de kwaliteit van afgestudeerde studenten te verhogen?

Weinig, dat zit idd bij de studenten zelf. Het trieste niveau van de gemiddelde Nederlandse (of eender welk land) ICT'er zit 'm meer in dat er zo weinig mensen met een programmeerafwijking geboren worden en dat het een van de takken van sport is die je iemand die het echt niet kan ook niet geleerd krijgt.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 123% gewijzigd door Ruudjah op 02-12-2009 00:24 ]

[frickY]

offtopic:
Ah, had het topic uit het oog verlogen. Even een paar maanden terug..

EfBe schreef op dinsdag 29 januari 2008 @ 10:38:
Dus: tabelnamen: enkelvoud en niet afkorten.
veldnamen: NIET prefixen. Het veld Naam in Product is de naam van .... juist, het product. Anders krijg ik Product.ProductNaam, beetje overbodig.

Ik denk dat ik liever een query zie met p.productNaam dan product.naam AS productNaam
Helemaal omdat een collega in een toekomstige wijziging in een nieuwe query misschien wel besluit te aliassen naar produktNaam. Dan kun je de noodzaak daarvan dan toch maar beter voorkomen?

Voorbeeld. Het selecteren van een artikel uit een subcategorie binnen een categorie, zonder prefixen.

SQL:

SELECT
  artikel.naam
  subcategorie.naam,
  categorie.naam,
FROM artikel
INNER JOIN categorie AS subcategorie ON subcategorie.id = artikel.categorieId
INNER JOIN categorie ON categorie.id = subcategorie.parentId

Als je deze resultset terug laat geven als array of object, heeft deze maar 1 waarde; naam.
Dan zou je in dit geval alle 3 de kolommen moeten aliassen

Waarom ben je zo bang dat je wat characters teveel moet tikken in sommige gevallen? (Terwijl je juist in andere gevallen overbodige text erbij tikt!)

Dat heeft niets met tikken te maken, maar met overzicht.
In mijn database-verkenner heb ik ~300px ruimte voor tabelnamen, en de rest van mijn resolutie voor de kolommen. Dan zie ik liever alles in één oogopslag dan dat ik moet gaan scrollen.
In een database achter een webwinkel is het voor iedereen denk ik makkelijk gokken wat er in een tabel "prodcats" met de kolommen "productID" en "categorieID" wordt opgeslagen?

Janoz schreef op dinsdag 29 januari 2008 @ 11:16:
Nee, ik loop niet te kutten met cijfertjes. Ja, ik fetch met cijfertjes, maar op de regels erboven staat precies een opsomming van de velden incl hun volgorde die vervolgens vlak daar onder middels de setters in het value object worden gezet.

En dan set je de value "naam" uit de kolom "product" in een property "productNaam", en het value uit "naam" uit de tabel "categorie" in "categorieNaam" Wat is hierdan het voordeel van boven wel prefixen en gewoon named fetchen, en dus die hele mapping overslaan?

curry684 schreef op dinsdag 29 januari 2008 @ 11:18:
Waarom niet? De query schrijft al voor in welke volgorde je je velden select, dan maakt het in theorie weinig uit of je vervolgens by name of index eraan refereert. De code moet je toch meeveranderen als je de query wijzigt, dus waarom daar geen strakke relatie tussen leggen?

Omdat je 100 regels verder niet meer weet welke index naar welke kolom refereert, of omdat je gedwongen wordt nieuwe kolommen aan het eind van de SELECT toe te voegen omdat je anders al je indexen opnieuw kan gaan lopen nummeren?

Tenzij je je SELECT opbouwt met een array en diezelfde array vervolgens ook weer gebruikt om de numerieken indexen te mappen naar named elementen... maar dan kies ik toch liever voor het prefixen van die kolommen en in een keer mijn result named op te halen.
Maar grappig dat je je PK wél prefixed, terwijl de andere kolommen net zo goed uniek zijn voor die entitiet (een kolom 'naam' in een tabel 'product' is heel wat anders dan een veld 'naam' in een tabel 'gebruikers').

Jammer dat hier na pagina 1 niet verder op door is gegaan, maar misschien bij deze alsnog

[Cousin Boneless]

En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.

Wat een waanzinnig slecht voorbeeld.. je moet a) hier je database structuur gaan wijzigen als een gebruiker meer dan 2 screen_names, meer dan 3 work_histories of meer dan 3 afiliations heeft.
En b) als je hierover een query gaat loslaten ('geef mij alle screen_names') moet je naar verschillende velden kijken. Voel een ontzettende spagetti code opkomen, zowel in sql als in de business objecten.

Er zijn best redenen te vinden om bepaalde zaken niet te normaliseren, maar de reden dat je 6 joins lelijk vindt, hoort daar nou net niet bij. Dat is toch netjes weggewerkt in de business layer als het goed is, en als die laag ontbreekt, is er hooguit één plek waar je al deze informatie tegelijk toont: de detailview van de user. En op die plek heb je geen database performance nodig.

This works -- queries are now blindingly simple (select * from users), and probably blindingly fast, as well. But you'll have a bunch of gaping blank holes in your data, along with a slew of awkwardly named field arrays. And all those pesky data integrity problems the database used to enforce for you? Those are all your job now. Congratulations on your demotion!

Edit: Ow.. was ook bedoeld als slecht voorbeeld

[ Voor 24% gewijzigd door Cousin Boneless op 15-07-2008 23:05 ]

[remco_k]

Normalisatie: Ik durf te zeggen dat ik, als ik een database ontwerp maak of aanpas, altijd normaliseer. Maar soms (of eigenlijk bij 90% van mijn opdrachten) heb ik te maken met derden die de database hebben ontworpen en ook een reeks applicaties daaromheen en daar mag ik dan op inhaken met een reeks applicaties van mij en ook een aantal aanpassingen aan de database doen.

... En van dat laatste heb ik momenteel last.
Ben bezig met een bron database van de klant, die heeft de database en een applicatie laten ontwikkelen, jaren geleden bij iemand anders. Kijkend naar die database heeft er iemand een keer heel goed over nagedacht. Duidelijke naamgeving, voor zo'n beetje elke manier van data verkeer is een stored procedure aangemaakt, en bijna alle mogelijke constraints om curruptie te voorkomen zitten erin... Bijna alle... En helaas op 1 of 2 plekken geen normalisatie. Dat vergeef ik de ontwikkelaar nog, want de database is huge qua opzet.
Nu heb ik de eer om rondom die database een aantal uitbreidingen op te doen, dmv synchronisatie van en naar een andere database met een compleet ander datamodel wat wij ook niet hebben ontwikkeld.
En daar begint de pret: die andere database is grotendeels niet genormaliseerd. En in de bron database zijn heel veel records in bepaalde tabellen die door een probleem in de applicatie nergens aan gejoint kunnen worden. Zijn zeg maar zwevende records. (heeft dat een naam eigenlijk?).
Bijkomend probleem in de doel database: iemand vond het kennelijk geil om in text velden in XML formaat lijsten met selectie opties voor pulldown comboboxen te zetten... Nu is dat misschien een leuk spielerijtje en handig voor 5 items maar niet als er 70000 in moeten. Trrrraaaaaaggggg... Had het dan gewoon comma seperated erin gezet, denk ik dan. (hoewel het dan nog niet genormaliseerd is).
En daar komt normalisatie ook om de hoe kijken, grote gedeeltes van die lijsten moeten dubbel die database in... Dat valt dus niet te normaliseren...
Gevolg: 15x ruim 70000 keuze opties in XML formaat de database in. Triest, maar waar.

Los het maar op, is mijn opdracht. Mag ik effe janken?
Uiteraard al het één en ander geprobeerd om in beweging te brengen maar de leveranciers van de databases en applicaties waar wij op in moeten gaan haken geven niet thuis. Zijn niet van plan om de hele wereld rondom ons aan te passen.
Dat word dus om andersmans nukken heen werken. Wish me luck en een paar weken werk.
(er staat dan wel een maar die is gewoon bedoeld voor de database ontwikkelaar die zo nat word van XML. Het is wel een mooi project waar ik nu aan werk, maar dit soort geneuzel hoef ik echt niet bij elk project te hebben. Dan kan je me over een paar jaar in een gesticht stoppen.)

[ Voor 11% gewijzigd door remco_k op 15-07-2008 23:43 ]

[BikkelZ]

Ruudjah schreef op dinsdag 15 juli 2008 @ 20:59:
Om weer ontopic te gaan (discussie ging lichtelijk richting offtopic). Na dit topic weggeklikt te hebben (mijn dagelijkse GoT-tine) natuurlijk even de dagelijkse Atwood-tine. En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.
Met name deze uitspraak is gepeperd en het waard om over te discusiieren:

[...]

Wat je hier ziet is een gevalletje premature optimalisatie. Als jouw social networking site 100.000 users heeft dan heb je het niet meer over een probleem, maar over een succes, ook al moet je bepaalde aanpassingen gaan doen in je database om eventuele performanceproblemen op te lossen. Als je dat allemaal van te voren gaat doen en een suboptimale bug gevoeligere opzet gaat doen van je database kom je misschien niet eens aan de 100.000 users in de eerste plaats, omdat de boel te vaak plat ligt of kuren heeft.

Overigens zijn goede joins helemaal niet zo duur, zeker niet in goed geschreven geprecompileerde stored procedures.

remco_k schreef op dinsdag 15 juli 2008 @ 23:37:Zijn zeg maar zwevende records. (heeft dat een naam eigenlijk?).

Ja.

Zwevende records.

Overigens bestaan 80% van de kosten die gemaakt worden in dat soort projecten in het oplossen van problemen die uit scenario's voort komen die volgens de oorspronkelijke ontwikkelaar 'toch nooit zouden voorkomen'.

[ Voor 7% gewijzigd door BikkelZ op 16-07-2008 14:08 ]

[remco_k]

BikkelZ schreef op woensdag 16 juli 2008 @ 14:06:
[...]
Ja.

Zwevende records.

Ow, haha... Zo zie je maar...

Overigens bestaan 80% van de kosten die gemaakt worden in dat soort projecten in het oplossen van problemen die uit scenario's voort komen die volgens de oorspronkelijke ontwikkelaar 'toch nooit zouden voorkomen'.

Dat is precies wat hier nu aan de hand is; ik ben al ver over de geoffereerde tijd heen, alleen maar bezig geweest met uitdokteren hoe ik om andermans problemen heen kan draaien. Zojuist een begin gemaakt aan het eindproduct...

[D-Raven]

Zo. ik was het hele topic alweer vergeten. Zie nu pas wat voor een reacties ik tussen EfBe en BikkelZ heb losgemaakt

Normaliseren. Ik doe het bijna eigenlijk altijd. Of beter gezegd, ik kom vaak op een genormaliseerd model uit. Beginnend bij een conceptueel model wordt er gekeken welke gegevens we willen opslaan, en wat we daarmee willen doen. Daar komt dan vanzelf een database model uit. Vaak leid dit tot een, niet helemaal uit genormaliseerde, representatie van de 2de NV.

Wat betreft het prefixen van kolommen. Sorry BikkelZ ik heb nog steeds geen argumenten gehoord welke er mij toe bewegen om het wel te gaan doen. . Alle technische voor en nadelen terzijde, uiteindelijk komt het aan op leesbaarheid en onderhoudbaarheid. Welke soms natuurlijk ook weer onderhevig is aan persoonlijke voorkeuren.

Ik werk dagelijks met grote database waarbij er ook 1 bijzit die dus wel prefixing gebruikt in combinatie met rare afkortingen. Tabel PSH_ProductStatusHistorie met kolom PSH_ID bijvoorbeeld. Als je dan een koppeltabel hebt ofzow, dan krijg je dus bijvoorbeeld RKT_RelatieKoppelTabel met kolom RKT_PSH_ID.... . Echt daar gaan mijn nekharen van overeind staan. Leesbaar? Begrijpbaar?

Kijk ik kan me voorstellen dat je in bovengenoemde voorbeeld in het geval van een foreign key zoiets heb van, ProductStatusHistorieId is mij te lang, ik noem dat ding ProductStatusId, of zoiets dergelijks. Afhankelijk van de situatie kan ik me daar nog enigszins in vinden. Maar kolom prefixing? bleeh :shivers:

[BikkelZ]

D-Raven schreef op woensdag 16 juli 2008 @ 16:35:
Ik werk dagelijks met grote database waarbij er ook 1 bijzit die dus wel prefixing gebruikt in combinatie met rare afkortingen. Tabel PSH_ProductStatusHistorie met kolom PSH_ID bijvoorbeeld. Als je dan een koppeltabel hebt ofzow, dan krijg je dus bijvoorbeeld RKT_RelatieKoppelTabel met kolom RKT_PSH_ID.... . Echt daar gaan mijn nekharen van overeind staan. Leesbaar? Begrijpbaar?

RKT_ProductStatusHistorieID zou ik in dat geval gebruiken. Ik kort nooit of te nimmer een variabelenaam af. Ik geloof dat ik zonder pardon variabele- of functienamen van 40 tot 60 karakters in zet (ik moet het eens natellen) als dat er voor zorgt dat de functie ondubbelzinnig en onafgekort omschreven is.

Overigens ben ik heel blij met jou als je een netjes genormaliseerde database gemaakt hebt zonder prefixing, uiteindelijk is zo'n prefix maar een detail.

[BikkelZ]

remco_k schreef op woensdag 16 juli 2008 @ 16:24:
[...]

Ow, haha... Zo zie je maar...

Volgens mij zijn het officieel 'orphaned records', bedacht ik me net.

remco_k schreef op woensdag 16 juli 2008 @ 16:24:
[...]

Dat is precies wat hier nu aan de hand is; ik ben al ver over de geoffereerde tijd heen, alleen maar bezig geweest met uitdokteren hoe ik om andermans problemen heen kan draaien. Zojuist een begin gemaakt aan het eindproduct...

Maar had je die database al gezien toen je die offerte opstelde?

[remco_k]

BikkelZ schreef op donderdag 17 juli 2008 @ 11:21:
[...]
Maar had je die database al gezien toen je die offerte opstelde?

Nee; dat niet.
Ook maak ik de offertes nooit (ik ben developer) maar doet de sales manager dat, nadat hij mij om advies heeft gevraagd met de nodige info. Ik maak dan een staatje met daarin o.a. een schatting van het aantal arbeidsuren.
Maar dat info inwinnen van de developer, in dit geval bij mij, is heel erg incompleet gegaan.
Die 2 databases waren toen niet voorhanden en ik heb daar ook m'n zorg over uitgesproken. 'Maar dat zal toch wel goed komen?'... Ja hoor, de vraag is alleen hoeveel tijd dat kost.
En zie hier... Een volledig in de soep gelopen offerte.
*Gelukkig* komt dit vrijwel nooit voor bij ons, want echt lekker werkt dit ook niet. Sterker nog, ik schijn behoorlijk nauwkeurig vooraf arbeidsuren te kunnen inschatten. Voor de kleinere projecten (1 tot 3 werkdagen) lukt het me soms zelfs op het uur af.

[Janoz]

Modbreak:

Ik heb even een deel van de discussie afgesplitst naar Beloning developers en hun leidinggevenden

[berendhaan]

Soms ik normaliseren gewoon niet praktisch. Vooral als je kleine databasesjes hebt met maar 4 tabellen ofzo.

Meestal als ik een database opzet zo uit het niets is het meestal al genormaliseerd zonder dat ik er erg in heb.

[Creepy]

Soms is normaliseren niet praktisch omdat het maar om een paar tabellen gaat? Kan je dat eens verder uitleggen want ik kan me er niks bij voorstellen. Een DB groeit vaak en normaliseren is altijd praktisch omdat het je een hoop gezeik met queries en vaak ook performance scheelt

[BikkelZ]

Er is natuurlijk ook nog de nuance dat sommige mensen het leggen van foreign key constraints niet onder normaliseren verstaan. Met name uit de MySQL hoek werd dit van oudsher niet gedaan (omdat dat lang ook niet mogelijk was).

[Johnny]

Ik heb onlangs nog een database ontworpen voor een interactieve website bestaande uit 23 tabellen en heb op diverse plaatsen gezondigd.

De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Ook geldbedragen worden op diverse plaatsen dubbel opgeslagen. Het zou genoeg zijn om het subtotaal en het BTW-tarief op te slaan om zo het totaal te berekenen, maar doordat je die op verschillende manieren kan afronden is het in de slim om de uitkomst ook op te slaan in de database zodat daar in de toekomst geen verwarring over kan onstaan.

Ook zijn er enkele tabellen die gevuld worden door externe processen die informatie dubbel hebben en zelfs serialized data bevatten zodat er in de toekomst wellicht meer informatie aan kan worden onttrokken. Ook is het handig om een kopie te hebben van de exacte gegevens die werden toegestuurd mocht er ooit iets mis gaan met de verwerking daarvan, bij het debuggen is het ook handig.

[BikkelZ]

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Ik heb onlangs nog een database ontworpen voor een interactieve website bestaande uit 23 tabellen en heb op diverse plaatsen gezondigd.

De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Heb je dat ook daadwerkelijk getest of is dit een aanname? (Het is me overigens niet helemaal duidelijk wat je bedoelt)

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

Wat zei ik net nou nog over MySQL developers?

Ik geloof niet dat er veel databases zijn die MySQL kunnen kloppen wat FULLTEXT betreft. En FULLTEXT zelf is al een soort van geindexeerd als ik me niet vergis.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Maar zijn die queries doordat ze 'simpeler' zijn nu ook beter te onderhouden? Volgens mij moet je meer regels documentatie toevoegen dan je van het aantal regels in een query afscheert.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Ook geldbedragen worden op diverse plaatsen dubbel opgeslagen. Het zou genoeg zijn om het subtotaal en het BTW-tarief op te slaan om zo het totaal te berekenen, maar doordat je die op verschillende manieren kan afronden is het in de slim om de uitkomst ook op te slaan in de database zodat daar in de toekomst geen verwarring over kan onstaan.

Dit werd op de HvU dan ook aangedragen als hét voorbeeld van wanneer blind normaliseren niet gewenst was. Een instinkertje voor het tentamen! Je maakt een factuurregel aan, die gekoppeld is aan een productregel en eigenlijk alle informatie dupliceert.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Ook zijn er enkele tabellen die gevuld worden door externe processen die informatie dubbel hebben en zelfs serialized data bevatten zodat er in de toekomst wellicht meer informatie aan kan worden onttrokken. Ook is het handig om een kopie te hebben van de exacte gegevens die werden toegestuurd mocht er ooit iets mis gaan met de verwerking daarvan, bij het debuggen is het ook handig.

Ja maar die informatie gebruik je niet actief in je 'informatiesysteem' als ik het zo mag uitdrukken, dat is toch gewoon een soort logfile?

[Johnny]

BikkelZ schreef op vrijdag 18 juli 2008 @ 09:40:

Heb je dat ook daadwerkelijk getest of is dit een aanname? (Het is me overigens niet helemaal duidelijk wat je bedoelt)

Het komt er op neer dat je in plaats van 2 joins nu maar 1 join nodig hebt in bepaalde gevallen. En het is makkelijk bij het bekijken van de tabel zelf omdat je meteen kan zien welk record waar bij hoort. Het maakt weinig verschil in performance, en de keys in kwestie zullen toch niet veranderen, ze worden enkel aangemaakt of verwijderd.

Wat zei ik net nou nog over MySQL developers?

Ik geloof niet dat er veel databases zijn die MySQL kunnen kloppen wat FULLTEXT betreft. En FULLTEXT zelf is al een soort van geindexeerd als ik me niet vergis.

FULLTEXT is inderdaad een speciaal soort index. In het verleden heb ik deze aanpak, net zoals een wel genormaliseerde variant ook gebruikt. De genormaliseerde manier vereist dat gebruikte tags ook in je tabel met beschikbare tags staan terwijl je dat in de praktijk niet altijd wil, daarnaat heb je enorme hoeveelheden code nodig om geavanceerde selecties te maken van bepaalde tags terwijl je met FULLTEXT de database het allemaal kan laten afhandelen omdat die boolean operators ondersteunt bij het zoeken.

Maar zijn die queries doordat ze 'simpeler' zijn nu ook beter te onderhouden? Volgens mij moet je meer regels documentatie toevoegen dan je van het aantal regels in een query afscheert.

De data in kwestie worden enkel gebruikt in een datamodel dat wordt samengesteld uit 4 verschillende tabellen, er is een enkele klasse die de data uit de database of file-cache haalt en omzet naar het datamodel. Het aanpassen van de booleans vereist dus enkel het toevoegen van een property aan de functie die de booleans vertaalt naar properties en andersom, de queries hoeven daarvoor niet te worden gewijzigd.

Dit werd op de HvU dan ook aangedragen als hét voorbeeld van wanneer blind normaliseren niet gewenst was. Een instinkertje voor het tentamen! Je maakt een factuurregel aan, die gekoppeld is aan een productregel en eigenlijk alle informatie dupliceert.

[...]

Ja maar die informatie gebruik je niet actief in je 'informatiesysteem' als ik het zo mag uitdrukken, dat is toch gewoon een soort logfile?

Het is inderdaad een soort logfile, maar daar is toch niks mis mee? Beheerders kunnen via het CMS de gegevens inzien om te controleren wat er is binnengekomen, en de data kan ook gebruikt worden om andere data opnieuw te genereren. Allerlei logfiles gaan doorspitten is een stuk lastiger omdat je die niet zo makkelijk kan sorteren en filteren.

[Verwijderd]

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Een dergelijke 'overtreding' is men hier ook begaan.
Ik kan er 1 ding over zeggen: DOE HET NIET.

Dit pakket draait nu al een flinke poos en is in de loop der jaren door VELE mensen onderhouden en er valt gewoon niet meer vanaf te komen. Begrijpelijk is het al helemaal niet. En de reden die jij aanvoert om het te rechtvaardigen voor jezelf is al helemaal geen goede, pure gemakzucht ten koste van je overzichtelijkheid en onderhoudbaarheid.

[ Voor 27% gewijzigd door Verwijderd op 18-07-2008 14:52 ]

[Verwijderd]

ik kan het alleen maar eens zijn met wat worteltaart al gezegd heeft. Daarnaast snap ik de keuze voor een TINYINT al helemaal niet. Het argument is 'makkelijk uitbreidbaar' maar de keuze dan juist een beperking. Wat is er dan mis met een 32bits getal, dan heb je tenminste nog de ruimte...

[BikkelZ]

Wat is eigenlijk het probleem met JOINs? Mensen lijken er een soort natuurlijk afkeer van te hebben vaak die ik niet zo goed kan plaatsen.

Johnny schreef op vrijdag 18 juli 2008 @ 12:51:
[...]

De data in kwestie worden enkel gebruikt in een datamodel dat wordt samengesteld uit 4 verschillende tabellen, er is een enkele klasse die de data uit de database of file-cache haalt en omzet naar het datamodel. Het aanpassen van de booleans vereist dus enkel het toevoegen van een property aan de functie die de booleans vertaalt naar properties en andersom, de queries hoeven daarvoor niet te worden gewijzigd.

Ja maar dan zit er dus bullshit-data in je database die je niet kunt verklaren zonder de applicatie er boven. Komt er een tweede applicatie die daar gebruik van gaat maken moet die dat zelfde stuk code gaan bevatten. En wijzig je iets in applicatie 1 gaat applicatie 2 natuurlijk niet vanzelf mee.

Daarom moet je de database verantwoordelijk maken voor dat soort zaken (en maakte ik ook niet zo'n probleem over het FULLTEXT verhaal, want dan blijft het wel bij de database). Zo'n Unix-security bits achtige oplossing is vooral geeky en totaal niet nuttig.

Of moet de database ook op een 5 1/4" diskette passen?

Johnny schreef op vrijdag 18 juli 2008 @ 12:51:
[...]

Het is inderdaad een soort logfile, maar daar is toch niks mis mee? Beheerders kunnen via het CMS de gegevens inzien om te controleren wat er is binnengekomen, en de data kan ook gebruikt worden om andere data opnieuw te genereren. Allerlei logfiles gaan doorspitten is een stuk lastiger omdat je die niet zo makkelijk kan sorteren en filteren.

Nee exact maar dan zijn het gegevens die toevallig ook in een database staan, en hoort het niet bij je daadwerkelijke gegevensmodel.

Gebruik je wel foreign keys en dat soort constraints om integriteit ook af te dwingen in het deel wat daar wel bij hoort? Met InnoDB ging dat wel prima eigenlijk.

[LauPro]

BikkelZ schreef op vrijdag 18 juli 2008 @ 16:20:
Daarom moet je de database verantwoordelijk maken voor dat soort zaken (en maakte ik ook niet zo'n probleem over het FULLTEXT verhaal, want dan blijft het wel bij de database). Zo'n Unix-security bits achtige oplossing is vooral geeky en totaal niet nuttig.

Er bestaat zo'n mooi lijstje van 'a database is not a calculator' etc. Allemaal stuk voor stuk nuttige tips die je zeker moet toepassen.

Toch typeren veel projecten zich als een lekkende kraan. Dat is prettig omdat het werk genereert. In mijn ogen is dan ook het leveren van een superieure oplossing de doodsteek voor elk softwarehuis.

De keuze tussen wel/niet normaliseren is gewoon een geldkwestie. Een opdrachtgever zal nooit vragen om te normaliseren, het is iets wat je als developer zelf moet inschatten en moet kunnen verantwoorden. En wat dat betreft is uitgaande van een ongenormaliseerde situatie normaliseren duur:
- structurele aanpassing (informeren DBA etc);
- terugwaardse compatibiliteit met back-up gaat verloren;
- er moet worden geconverteerd;
- aanpassingen in software (DBL).

Neemt niet weg dat de performance en consistentie van een ongenormaliseerde database op een gegeven moment dermate rampzalig kan zijn waardoor de situatie onwerkbaar wordt.

[remco_k]

LauPro schreef op zaterdag 19 juli 2008 @ 01:03:
[...]
Er bestaat zo'n mooi lijstje van 'a database is not a calculator' etc. Allemaal stuk voor stuk nuttige tips die je zeker moet toepassen.

Toch typeren veel projecten zich als een lekkende kraan. Dat is prettig omdat het werk genereert. In mijn ogen is dan ook het leveren van een superieure oplossing de doodsteek voor elk softwarehuis.

De keuze tussen wel/niet normaliseren is gewoon een geldkwestie. Een opdrachtgever zal nooit vragen om te normaliseren, het is iets wat je als developer zelf moet inschatten en moet kunnen verantwoorden. En wat dat betreft is uitgaande van een ongenormaliseerde situatie normaliseren duur:
- structurele aanpassing (informeren DBA etc);
- terugwaardse compatibiliteit met back-up gaat verloren;
- er moet worden geconverteerd;
- aanpassingen in software (DBL).

Neemt niet weg dat de performance en consistentie van een ongenormaliseerde database op een gegeven moment dermate rampzalig (kan) zijn waardoor de situatie onwerkbaar wordt.

Hier kan ik het volledig mee eens zijn. Het feit dat de opdracht gever nooit om normaliseren op zich vraagt, komt denk ik eerder omdat ze niet eens weten dat het bestaat. Wel komt de opdrachtgever met de 'wil je dit optimaliseren' vraag en daar heeft hij dan 2 doelen bij:
1. Snelheid
2. De grootte van de database beperken, wat an sich ook weer snelheidswinst kan opleveren.
Wat mij betreft is normaliseren dan één van de dingen die moet gebeuren, maar het is wel de meest ingrijpende verandering.

Als je een database niet (goed) normaliseerd, dan is het vaak te laat om dat wel te doen op het moment dat je merkt dat de performance, consistentie of schijfruimte problemen op gaat leveren.
1 van de projecten waar ik regelmatig mee in aanraking kom betreft een database met een filesize van >35 GB (ja, met de G en nee er zitten geen blobs en grote textvelden in, alleen 'pure data' van ints en chars[255] en een enkele van >255). *Gelukkig* is daar alles genormaliseerd, anders zou deze database wellicht 2x zo groot zijn. Ik ben als trotse 'vader' bij de geboorte van die database geweest.
Dat wil niet zeggen dat alles perfect is aan die database overigens.

[Ruudjah]

Voor versiebeheer heb ik ook gezondigd. Maar de vraag is of dat zondigen is; ik ben er nog niet echt over uit. Wat er gebeurd is dat we data op in een XML bestand opslaan. Bij een wijziging van die data wordt er simpelweg een nieuw bestand opgeslagen met hierin alle data gekopieerd (behalve natuurlijk de wijzigingen). Omdat in de definitie van het XML bestand ook data staat die read-only is en dus nooit gewijzigd wordt, is bij elke save van de gebruiker die data redundant gepersisteerd. In principe is dat een overtreding van normaliseren: nooit data dubbel opslaan als dit niet nodig is. Maar het model is simpel en makkelijk om mee te ontwikkelen. Verder hebben we nu als voordeel dat als, om wat voor reden dan ook de oudere versies niet meer aanwezig zijn, de (redundante read-only) data nog wel beschikbaar is.
Ik vind het een pragmatische oplossing die voor ons werkt. Ook al overtreedt ik dan de normalisatieregels met voeten.

En Hongaarse notatie: waarom moet er legacy onderwezen worden?

Ik heb ook geen idee wat de hongaarse notatie precies inhoudt. Het gaat mij erom dat in ieder geval een notatie bekend is voor de studenten. Dat is er vaak nog niet eens. Of je nu de Hongaarse, Zwitserse, West-Australische of Noord-Japanse pakt interreseert me niet zoveel.

[ Voor 15% gewijzigd door Ruudjah op 20-07-2008 19:40 ]

[whoami]

Ruudjah schreef op zondag 20 juli 2008 @ 19:37:
Voor versiebeheer heb ik ook gezondigd. Maar de vraag is of dat zondigen is; ik ben er nog niet echt over uit. Wat er gebeurd is dat we data op in een XML bestand opslaan. Bij een wijziging van die data wordt er simpelweg een nieuw bestand opgeslagen met hierin alle data gekopieerd (behalve natuurlijk de wijzigingen). Omdat in de definitie van het XML bestand ook data staat die read-only is en dus nooit gewijzigd wordt, is bij elke save van de gebruiker die data redundant gepersisteerd. In principe is dat een overtreding van normaliseren: nooit data dubbel opslaan als dit niet nodig is. Maar het model is simpel en makkelijk om mee te ontwikkelen. Verder hebben we nu als voordeel dat als, om wat voor reden dan ook de oudere versies niet meer aanwezig zijn, de (redundante read-only) data nog wel beschikbaar is.
Ik vind het een pragmatische oplossing die voor ons werkt. Ook al overtreedt ik dan de normalisatieregels met voeten.

Jij noemt een XML bestand een databank ?

Ruudjah schreef op dinsdag 15 juli 2008 @ 20:59:
Om weer ontopic te gaan (discussie ging lichtelijk richting offtopic). Na dit topic weggeklikt te hebben (mijn dagelijkse GoT-tine) natuurlijk even de dagelijkse Atwood-tine. En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.
Met name deze uitspraak is gepeperd en het waard om over te discusiieren:

[...]

Hmm .... Een datamodel waar over nagedacht is, en dat genormaliseerd is, en later gedenormaliseerd waar nodig, zorgt voor een goede, solide basis. Een basis die je garanties kan bieden over de correctheid van de data, en die voor een goede basis performance kan zorgen.

Ik heb ook geen idee wat de hongaarse notatie precies inhoudt. Het gaat mij erom dat in ieder geval een notatie bekend is voor de studenten. Dat is er vaak nog niet eens. Of je nu de Hongaarse, Zwitserse, West-Australische of Noord-Japanse pakt interreseert me niet zoveel.

Als programmeur moet de term 'hongaarse notatie' toch wel een belletje doen rinkelen. Je moet toch min of meer weten wat hiermee bedoeld wordt; echter, dat betekent niet dat je 't moet gebruiken. Ik heb er zelf een hekel aan.
klik

D-Raven schreef op woensdag 16 juli 2008 @ 16:35:

Wat betreft het prefixen van kolommen. Sorry BikkelZ ik heb nog steeds geen argumenten gehoord welke er mij toe bewegen om het wel te gaan doen. . Alle technische voor en nadelen terzijde, uiteindelijk komt het aan op leesbaarheid en onderhoudbaarheid. Welke soms natuurlijk ook weer onderhevig is aan persoonlijke voorkeuren.

Tja, naming guidelines zijn subjectief. Iedereen heeft daar zijn eigen 'best practices', en iedereen vind dan weer iets anders lekkerder werken.
Mijn boodschap is: werk je voor een bedrijf, en ze hebben daar guidelines, dan volg je die.
Werk je aan hobby projectjes, etc... of werk je voor een bedrijf waar ze geen guidelines hebben, stel dan je eigen guidelines samen en volg die, en wees consequent.

berendhaan schreef op donderdag 17 juli 2008 @ 20:38:
Soms ik normaliseren gewoon niet praktisch. Vooral als je kleine databasesjes hebt met maar 4 tabellen ofzo.

Meestal als ik een database opzet zo uit het niets is het meestal al genormaliseerd zonder dat ik er erg in heb.

Geef hier eens wat meer uitleg over ? Waarom zou het in dat geval niet nodig zijn om te normaliseren ? Waarom zou je in dergelijke gevallen wel gedupliceerde data toelaten bv ?

Trouwens, meestal ga je eerst normaliseren en ga nadien pas zien hoeveel tabellen je zult hebben
(Al is het natuurlijk wel zo dat je bij kleine projecten meestal wel al zo op het zicht kunt zien welke en hoeveel tabellen je zult hebben).

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Alsof een JOIN zo duur is .... Nuja, meer kan ik er natuurlijk niet over zeggen want ik zie de situatie niet voor me.

Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

En wat als je een tag wilt verwijderen ? Of wat als je een tag een andere naam wilt geven, en die tag wordt door meerdere teksten gebruikt ?
Kan je mij eens uitleggen wat het voordeel is van een dergelijke, ranzige shortcut tov het gewoon te doen zoals het zou moeten ?

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Waarom heb je die bools nodig als ze niet hoeven doorzocht te worden ?
Nu is het misschien makkelijk, maar wat na 4 jaar bv ? Zal jij nog weten wat die tinyint juist is, en wat de betekenis is van iedere bool op iedere positie ?
Of, wat als iemand anders die DB in z'n pollen geschoven krijgt om 'm verder te onderhouden, te ontwikkelen ?
Ik heb onlangs op m'n werk ook een legacy DB herbouwd die ook dergelijke truken gebruikte; wel, ik kan je zeggen. Er was niemand die nog precies wist hoe die legacy DB in elkaar zat.

Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Hier ben ik het met je eens.

Kijk, een 'stielman' moet zich, bij het uitoefenen van z'n beroep houden aan 'de regels van de kunst', en er wordt ook van hem verwacht dat hij die regels kent en toepast. Als hij bv een huis bouwt, en de bouwheer / klant heeft een probleem, en de oorzaak van dat probleem heeft te maken met het werk dat die stielman heeft uitgevoerd, wel, dan heeft die beste man een probleem als blijkt dat zijn werk niet 'volgens de regels van de kunst' is uitgevoerd.
Wel, als ik dergelijke dingen hier lees, dan ben ik een zeer zwaar voorstander om dergelijke 'regels' ook op te leggen aan software-ontwikkelaars.

/reply-combo.

[ Voor 70% gewijzigd door whoami op 20-07-2008 20:05 ]

[Ruudjah]

Jij noemt een XML bestand een databank?

Ja, natuurlijk. Ook een XML structuur moet je in den beginne normaliseren. Een XML definitie is ook gewoon een datamodel, net als een datamodel op een database server.

[whoami]

Ruudjah schreef op zondag 20 juli 2008 @ 19:57:
[...]

Ja, natuurlijk. Ook een XML structuur moet je in den beginne normaliseren. Een XML definitie is ook gewoon een datamodel, net als een datamodel op een database server.

Nee, natuurlijk niet.
Een XML bestand bevat niet noodzakelijk 'gestructureerde informatie'.
Met een XML bestand kan je niet garanderen dat je operaties (opslaan / wijzigen) atomair zijn
etc...

om dan nog maar over de performance te zwijgen.

[Ruudjah]

Met een XML bestand kan je niet garanderen dat je operaties (opslaan / wijzigen) atomair zijn
etc...

om dan nog maar over de performance te zwijgen.

Dan nog blijft het een datamodel. Ik zie niet in hoe de door jouw genoemde punten het opeens géén datamodel meer is?

[whoami]

Ik heb niet gezegd 'een datamodel', ik heb gezegd 'een databank', want dat is wat je nu toch doet ?
Je misbruikt een xml bestand om het te gebruiken als databank.

[Ruudjah]

Databank, datamodel. mjah. Een XML definitie vind ik wel degelijk een datamodel. Afhankelijk van je definitie is [zijn de instanties van de XML definitie] het ook een databank.
Overigens misbruik ik helemaal niets.

[ Voor 9% gewijzigd door Ruudjah op 20-07-2008 21:23 ]

[Johnny]

whoami schreef op zondag 20 juli 2008 @ 19:46:
[...]
Alsof een JOIN zo duur is .... Nuja, meer kan ik er natuurlijk niet over zeggen want ik zie de situatie niet voor me.

Alsof een extra kolom zo duur is... Hij is technisch gesproken dubbelop, maar deze foreign key is ook meteen een unique identifier die overal zichbaar, en daardoor ook herkenbaar is. Het is meteen duidelijk voor iedereen waar een bepaald record bij hoort.

En wat als je een tag wilt verwijderen ? Of wat als je een tag een andere naam wilt geven, en die tag wordt door meerdere teksten gebruikt ?
Kan je mij eens uitleggen wat het voordeel is van een dergelijke, ranzige shortcut tov het gewoon te doen zoals het zou moeten ?

Zoals ik al eerder heb uitgelegd kan je op deze manier gebruikmaken van FULLTEXT zoekmogelijkheden waardoor het voor de gebruiker heel makkelijk is om gevavanceerde selecties te maken bestaande uit meerdere tags, inclusief operators zoals AND, OR en NOT zonder dat je daar veel extra code voor nodig hebt.

Een tag een andere naam geven komt in de praktijk vrijwel nooit voor, ik gebruik deze methode al 2 jaar voor diverse websites en heb in die tijd één keer een tag moeten vervangen omdat die verkeerd bleek te zijn ingevoerd, en dat kan met een simpele REPLACE query.

Een tag verwijderen is ook niet problematisch, je kan er dan voor kiezen om hem uit de tabel van beschikbare tags te gooien en dan verschijnt hij niet meer op de pagina's waar de beschikbare tags staan en kan hij niet meer worden toegevoegd. Meestal kan hij wel gewoon bij bestaande content blijven staan, en zelfs al is dat niet geval dan is het ook weer met een eenmalige query op te lossen.

De genormaliseerde manier gebruikte ik voordat ik met deze methode begon, en nog steeds in oudere systemen en die is minder flexibel en vereist veel meer code en heeft alsnog minder mogelijkheden.

Het is voor mij de ideale manier om content te voorzien van tags omdat je mensen laat kiezen uit een aantal vooraf bepaalde woorden zodat ze geen rare dingen zelf gaan verzinnen maar tegelijkertijd flexibel genoeg bent om toch nog andere tags kan voegen en gebruik kan maken van de faciliteiten van de database.

Waarom heb je die bools nodig als ze niet hoeven doorzocht te worden ?
Nu is het misschien makkelijk, maar wat na 4 jaar bv ? Zal jij nog weten wat die tinyint juist is, en wat de betekenis is van iedere bool op iedere positie ?
Of, wat als iemand anders die DB in z'n pollen geschoven krijgt om 'm verder te onderhouden, te ontwikkelen ?
Ik heb onlangs op m'n werk ook een legacy DB herbouwd die ook dergelijke truken gebruikte; wel, ik kan je zeggen. Er was niemand die nog precies wist hoe die legacy DB in elkaar zat.

Het gaat hier om een aantal booleans die de manier waarop invoervelden worden weergegeven bepalen, niet een criterium waar je zou willen zoeken (wat overginds wel mogelijk is met een bitmask), zelf als ze niet aanwezig zijn blijft het systeem werken, maar dan met de standaardweergave. De betekenis zou je ook simpel kunnen vastleggen als comment bij de kolomnaam.

Desondanks heb ik de TINYINT nu vervangen door een aantal losse BIT(1) kolommen wat ook een redelijk efficiente manier is om meerdere booleans op te slaan.

[Verwijderd]

Heel vaak kom ik tegen dat men, het lijkt bijna een gemeengoed te zijn, een surrogate key tooevoegd om een rij in de tabel uniek te maken binnen de tabel. Veel mensen doen dit standaard, ook wanneer er gewoon een primary key is zoals het klantnummer in een klanttabel (even ervan uitgaande dat de klantnummers van ex-klanten niet opnieuw uitgegeven worden). Hoe staan jullie hier tegen over?

Wanneer er dan geen unieke key op basis van een kolom is te vinden dan kun je vaak nog wel een samengestelde key vinden zoals het factuurnummer + factuurregelnummer. In een factuurdetail tabel. Kiezen jullie in deze gevallen dan liever voor een surrogate key?

[whoami]

Verwijderd schreef op dinsdag 19 augustus 2008 @ 15:41:
Heel vaak kom ik tegen dat men, het lijkt bijna een gemeengoed te zijn, een surrogate key tooevoegd om een rij in de tabel uniek te maken binnen de tabel. Veel mensen doen dit standaard, ook wanneer er gewoon een primary key is zoals het klantnummer in een klanttabel (even ervan uitgaande dat de klantnummers van ex-klanten niet opnieuw uitgegeven worden). Hoe staan jullie hier tegen over?

Ik ben voor surrogate keys.
Waarom :
- gegarandeerd uniek
- gegarandeerd onveranderlijk, het stelt nl. geen 'business gegeven' voor dat per definitie zou kunnen wijzigen.
- primary keys zullen dan ook nooit composite keys zijn, waardoor je foreign keys ook simpel blijven
- het maakt het leven makkelijker als je een O/R mapper al NHibernate gebruikt.

Wanneer er dan geen unieke key op basis van een kolom is te vinden dan kun je vaak nog wel een samengestelde key vinden zoals het factuurnummer + factuurregelnummer. In een factuurdetail tabel. Kiezen jullie in deze gevallen dan liever voor een surrogate key?

Ja dus.

Wat is het doel van een primary key ? Gewoon een stukje 'administratie' voor het DBMS om een rij uniek te kunnen identificeren.
Laat ik de vraag eens omdraaien: waarom zou je voor een natural key kiezen ?

[joppybt]

whoami schreef op dinsdag 19 augustus 2008 @ 15:48:
Laat ik de vraag eens omdraaien: waarom zou je voor een natural key kiezen ?

• Je hebt geen extra kolom nodig
• Je hebt geen extra index nodig
• (Oracle) je hebt geen extra sequence nodig
• (Oracle) je hebt geen extra trigger nodig om die sequence in de primary key te zetten

Ofwel: je haalt je met surrogate keys wel wat overhead op de hals. Je zult moeten afwegen of dat tegen de voordelen opweegt.

[mOrPhie]

Ik denk dat die overhead wel meevalt. Ik herken de surrogate key of de identity-column van MS SQL Server niet als performance-bottleneck eigenlijk. Nog nooit heb ik iemand horen zeggen: "die identity-columns zijn met toch een doorn in het oog zeg, wat zijn die traag".

Ik vind het gevaarlijk om datalogica af te laten hangen van iets wat businesslogica zou kunnen zijn. Iemand zou zomaar de business-rules kunnen wijzigen. Een klantnummer kan nu bijvoorbeeld heel goed numeric zijn, maar als je opdrachtgever morgen bedenkt dat het klantnummer wordt aangevuld met een letter, dan hang je. En dan kun je op je kop gaan staan, die letter komt er toch wel, maar jouw gehele applicatie staat vol met selecties op tabellen waarbij uit wordt gegaan van integers.

Nog een voorbeeld: stel dat die klantnummers (in dit geval, zou ook een andere unieke waarde kunnen zijn) worden gezien als belangrijke persoonsgegevens die niet zomaar publiek mag worden, maar je moet wel een soort extranet-site maken waarin sommige informatie te zien is. Waarop ga je op dat moment je selectie baseren? De unieke waarde is geen onderdeel van de publieke informatie en mag dus niet in de URL staan, of als POST informatie over de lijn heen gaan. Het is wat cryptisch, maar een dergelijk scenario heb ik zelf meegemaakt.

De enige keren dat ik niet voor een extra kolom zou kiezen is bij koppeltabellen. Maar zelfs daar vind ik het administratief gezien geen overdaad om een extra identiteit aan de tabel te hangen.

[Verwijderd]

De enige keren dat ik niet voor een extra kolom zou kiezen is bij koppeltabellen. Maar zelfs daar vind ik het administratief gezien geen overdaad om een extra identiteit aan de tabel te hangen.

Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

[Orphix]

Verwijderd schreef op dinsdag 19 augustus 2008 @ 18:10:
Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

Omdat het werken met primary keys over meerdere velden (zoals bij keys) in je programmatuur lastiger is. Het is gewoon eenvoudiger om consistent overal een Id aan te hangen en dat je altijd op id==localId kunt zoeken, filteren, etc. Ipv altijd where veld1=.. && veld2=.. Tuurlijk, het is geen harde noodzaak maar het brengt in mijn ervaring wel veel gemak met zich mee.

[mOrPhie]

Verwijderd schreef op dinsdag 19 augustus 2008 @ 18:10:
[...]

Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

Soms heb je een view vanuit de koppeling. Bijvoorbeeld een zakelijke relatie (linkedin oid, ik noem maar wat). Je hebt twee partijen (bedrijven of mensen), maar ook bijvoorbeeld hoe de relatie tot stand kwam, wanneer, opmerkingen, enz. Het is nog altijd een koppeltabel, maar je bekijkt het vannuit de koppeling zelf. In dergelijke gevallen kan het gewenst zijn de koppeling met een enkel id te selecteren.

[Janoz]

Het voorbeeld van MorPhie lijkt exotisch en is misschien daarom lastig voor te stellen:

mOrPhie schreef op dinsdag 19 augustus 2008 @ 16:50:
Ik vind het gevaarlijk om datalogica af te laten hangen van iets wat businesslogica zou kunnen zijn. Iemand zou zomaar de business-rules kunnen wijzigen. Een klantnummer kan nu bijvoorbeeld heel goed numeric zijn, maar als je opdrachtgever morgen bedenkt dat het klantnummer wordt aangevuld met een letter, dan hang je. En dan kun je op je kop gaan staan, die letter komt er toch wel, maar jouw gehele applicatie staat vol met selecties op tabellen waarbij uit wordt gegaan van integers.

Maar denk bijvoorbeeld eens aan fusies? De klanten administratie systemen van Casema, Multikabel en @Home die nu allemaal gemerged moeten worden. @Home had uberhaupt al moeite om hun tv kabel klanten bestand te kunnen koppelen aan het internet klanten bestand.

[Voutloos]

De mensen uit het 'surrogate keys zijn nergens voor nodig'-kamp hechten gewoon veel te veel waarde aan de letterlijke inhoud van een primary key. Maar of die synthetische key 42 of 1337 is moet nergens boeien, en extern hoeft het uberhaupt niet zichtbaar te zijn of waarde te hebben.

[Verwijderd]

Voutloos schreef op woensdag 20 augustus 2008 @ 14:44:
De mensen uit het 'surrogate keys zijn nergens voor nodig'-kamp hechten gewoon veel te veel waarde aan de letterlijke inhoud van een primary key. Maar of die synthetische key 42 of 1337 is moet nergens boeien, en extern hoeft het uberhaupt niet zichtbaar te zijn of waarde te hebben.

Ik vind het ook wel gewoon lekker makkelijk hoor om een surrogate key te gebruiken maar de overweging ja/nee blijf altijd wel door mijn hoofd spelen. En als ik dan kies voor ja dan pas ik dit toe in het hele model om zo geen verwarring te scheppen. Ook al zal die niet zo snel ontstaan omdat ik de enige ben die er mee werkt.
Ik ben het alleen niet eens met dat mensen te veel waarde aan hechten volgens jou. Het zijn juist informatie elementen die om die reden apart zijn. Stel je maakt een applicatie met 200 tabellen voor een grote organisatie en je moet het spul overdragen. De natuurlijk primary keys leggen zich zelf uit en dat doen ze niet meer wanneer je ze ongedaan maakt door er eigen keys te maken.

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik. Bij zo een providerfusie zullen zaken als verschillende productcatalogi structuren die samengevoegd moeten worden tot meer kopzorgen leiden.

[whoami]

De natuurlijk primary keys leggen zich zelf uit

Kan je hier eens wat over uitwijden ?
Hoezo, ze leggen zichzelf uit ? Wat bedoel je hiermee ? Je kan toch evengoed een unique constraint leggen op die column (of columns) waar je anders de PK zou op leggen ?

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik.

Aannames zijn fataal ...
Waarom zou dat niet voor problemen kunnen zorgen ? Stel bedrijf A neemt bedrijf B over en daarmee alle klanten. Bedrijf A stelt dan dat alle klanten van bedrijf B een nieuw klantennummer moet krijgen die voldoet aan het formaat van het klantnr dat ze al jaren hanteren.

Of, andere situatie, Bedrijf A neemt alle klanten van bedrijf B over, maar, nu zitten ze met klantnr's die elkaar overlappen ... Ojee.

[Janoz]

Verwijderd schreef op woensdag 20 augustus 2008 @ 15:02:
[...]


Ik vind het ook wel gewoon lekker makkelijk hoor om een surrogate key te gebruiken maar de overweging ja/nee blijf altijd wel door mijn hoofd spelen. En als ik dan kies voor ja dan pas ik dit toe in het hele model om zo geen verwarring te scheppen. Ook al zal die niet zo snel ontstaan omdat ik de enige ben die er mee werkt.
Ik ben het alleen niet eens met dat mensen te veel waarde aan hechten volgens jou. Het zijn juist informatie elementen die om die reden apart zijn. Stel je maakt een applicatie met 200 tabellen voor een grote organisatie en je moet het spul overdragen. De natuurlijk primary keys leggen zich zelf uit en dat doen ze niet meer wanneer je ze ongedaan maakt door er eigen keys te maken.

Een primary key zonder verdere betekenis hoef je helemaal niet verder uit te leggen want er valt helemaal niks over uit te leggen. Hij heeft namelijk helemaal geen betekenins zodra je buiten de database komt.

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik. Bij zo een providerfusie zullen zaken als verschillende productcatalogi structuren die samengevoegd moeten worden tot meer kopzorgen leiden.

whoami heeft het al aangegeven, maar ik blijf toch erg benieuwd waarom jij denkt dat het niet voor problemen gaat zorgen. Hoe zou jij het aanpakken dan?

[jos707]

De afkeer tegen 'surrogate keys' snap ik eigenlijk helemaal niet. Het gebruik van een surrogate key is de enige manier waar je 100% van kan uitgaan dat dit future proof is. Waarom een natural key gebruiken om dan het risico te lopen dat je vroeg of laat tegen een probleem aanloopt dat je records niet meer op een unieke manier benaderd kunnen worden?