Correct database ontwerp, koppeltabellen altijd?

[blijhoofd_bennie]

Ik wilde graag jullie mening horen over het correct ontwerpen van databases (en dan vooral over mijn gedacht daarover ) Hier gaan we dan


Ik een heel erge voorstander van koppeltabellen. Ook als deze niet direct nodig zijn. De reden waarom zal ik proberen uit te leggen aan de hand van een voorbeeld wat me zo te binnen schiet.

Voorbeeld 1:
Je verkoopt auto's en je wilt wat gegevens in een database opslaan. We slaan voor het gemak maar 2 dingen op, de naam van de auto en het merk.

Een database ontwerp zou kunnen zijn:

Merk (tabel)

MerkID
MerkNaam

Auto (tabel):
AutoID
AutoNaam
MerkID

In dit geval heeft de tabel merk een relatie met de tabel auto d.m.v. het MerkID. Dit kan in dit geval perfect omdat een auto maar 1 merk kan hebben. Het nadeel wat hier (volgens mij) aanzit is het volgende. Als ik een merk verwijderd kan dit niet, doordat er een relatie zit tussen de twee tabellen. Zou ik dan toch een merk willen verwijderen zou ik ook een auto moeten verwijderen (of het ID veld leeglaten en/of ander merk kiezen). Maar dit willen we niet. Ook al zijn er geen merken meer, de gegevens van de auto moeten beschikbaar blijven.


Voorbeeld 2 (zo zou ik het doen)

Merk (tabel)

MerkID
MerkNaam

Auto (tabel):
AutoID
AutoNaam

AutoMerk (koppeltabel)
AutoMerkID
AutoID
MerkID

De voordelen ten opzicht van voorbeeld 1 zijn wel duidelijk. Er wordt alleen een koppeling tussen de tabellen gemaakt. Als er in dit geval dus een merk zou verdwijnen zouden de gegevens over de auto in ieder geval blijven bestaan. Ook zou ik in dit geval meerdere merken aan 1 auto kunnen koppelen (als dit van toepassing mocht zijn natuurlijk). Een ander voordeel is dat het op deze manier veel meer uitbreid mogelijkheden heeft.

Ik zou hier graag jullie mening over willen horen, thanks

[gorgi_19]

Ik denk dat dat erg afhankelijk is van de situatie. Wat je als voorbeeld beschreef, kan volgens mij goed in voorbeeld 1. Alleen als je dus uitgaat van een variabel aantal merken, lijkt me een koppeltabel handig.. Al die tabellen, zeker bij enorme databases, zorgen voor onnodige overhead, lijkt me.:)

[ACM]

Euh, je ziet over het hoofd dat je koppeltabel-entries zinloos worden als je je merk verwijderd en dus je auto-database ook info verliest.

Waarom je zo 'moeilijk doet' weet ik niet, merken verdwijnen namelijk niet zo snel.
Sterker nog, een merk kan best ophouden met produceren van auto's maar de naam blijft wel degelijk bestaan/geldig als merk voor die auto's.

Oftewel, geen merk verwijderen als er nog auto's van zijn. De koppeltabel gebruik je over het algemeen alleen voor n op m relaties.

Verder verlies je uit het oog dat het natuurlijk mogelijk is de merken dan dmv een cascaded delete te laten verwijderen en de auto's bijv hun merkid op 'null' of op een default waarde te zetten.

[blijhoofd_bennie]

Op zondag 09 juni 2002 13:31 schreef gorgi_19 het volgende:
Ik denk dat dat erg afhankelijk is van de situatie. Wat je als voorbeeld beschreef, kan volgens mij goed in voorbeeld 1. Alleen als je dus uitgaat van een variabel aantal merken, lijkt me een koppeltabel handig.. Al die tabellen, zeker bij enorme databases, zorgen voor onnodige overhead, lijkt me.:)

Ok daar kan ik inkomen, maar als ik dan een merk/auto zou verwijderen zou ik bij het gebruik van een koppeltabel toch tegenover minder problemen komen te staan? Of zit ik er helemaal naast?

[ACM]

Op zondag 09 juni 2002 13:39 schreef blijhoofd_bennie het volgende:
Ok daar kan ik inkomen, maar als ik dan een merk/auto zou verwijderen zou ik bij het gebruik van een koppeltabel toch tegenover minder problemen komen te staan? Of zit ik er helemaal naast?

Gewoon merken niet verwijderen, evt markeer je een merk dat niet meer produceert dmv een boolean als 'inactief'

Auto's verwijderen is geen probleem.

Met je koppeltabel moet je ook steeds alle koppelingen bijwerken/toevoegen/verwijderen.

[blijhoofd_bennie]

Op zondag 09 juni 2002 13:36 schreef ACM het volgende:
Euh, je ziet over het hoofd dat je koppeltabel-entries zinloos worden als je je merk verwijderd en dus je auto-database ook info verliest.

Waarom je zo 'moeilijk doet' weet ik niet, merken verdwijnen namelijk niet zo snel.
Sterker nog, een merk kan best ophouden met produceren van auto's maar de naam blijft wel degelijk bestaan/geldig als merk voor die auto's.

Oftewel, geen merk verwijderen als er nog auto's van zijn. De koppeltabel gebruik je over het algemeen alleen voor n op m relaties.

Verder verlies je uit het oog dat het natuurlijk mogelijk is de merken dan dmv een cascaded delete te laten verwijderen en de auto's bijv hun merkid op 'null' of op een default waarde te zetten.

Je hebt helemaal gelijk, normaal zou mijn situatie niet kunnen. Maar de reden waarom ik wel zo 'moeilijk' doe zijn de volgende:

Ik wil altijd de gegevens van de auto (dit is wel een voorbeeld situatie, maar volgens mij heb ik niet echt een goede gekozen) behouden ook al bestaat het merk niet meer. Dus de gegevens van de auto staan los van het merk (zo zie ik het dan).

Tevens als er een fout op zou treden zou alleen de koppeling beschadigen en de gegevens die bij de koppelingen horen niet (weet niet of dit kan gebeuren, maar was zo een gedachten gang van mij).

Dat op null zetten was ik persoonlijk niet zo'n voorstander van (staat lomp). Maar dat met die default waarde had ik ff niet aan gedacht .

[Verwijderd]

Ut is niet zo moeilijk hoor. Je pakt een data modelleringstechniek, past de regels toe en uit je rollen-bollen diagram rolt een tabellenset. Ik snap die oeverloze discussies nooit omtrent 'is dit datamodel correct?' (en dan zien we een setje tabellen, maar geen model of data analyse resultaten die geleid hebben tot dat model)... Pas een modelleringstechniek toe en je bent klaar. Als je niet snapt wat een datamodelleringstechniek is: stay the f*ck away from databases.

[blijhoofd_bennie]

Op zondag 09 juni 2002 13:42 schreef ACM het volgende:

[..]



Met je koppeltabel moet je ook steeds alle koppelingen bijwerken/toevoegen/verwijderen.

Klopt, maar dan heeft een koppeltabel toch als voordeel dat het veel sneller werkt of kraam ik nu onzin uit?

[blijhoofd_bennie]

Op zondag 09 juni 2002 13:45 schreef Otis het volgende:
Ut is niet zo moeilijk hoor. Je pakt een data modelleringstechniek, past de regels toe en uit je rollen-bollen diagram rolt een tabellenset. Ik snap die oeverloze discussies nooit omtrent 'is dit datamodel correct?' (en dan zien we een setje tabellen, maar geen model of data analyse resultaten die geleid hebben tot dat model)... Pas een modelleringstechniek toe en je bent klaar. Als je niet snapt wat een datamodelleringstechniek is: stay the f*ck away from databases.

Ik probeer een overloze discussie te vermeiden, maar ik ga nu uit van de informatie die ik gevonden heb en ik wil graag de reactie van de mensen op dit forum horen omtrent de verzamelde informatie.

En zover je het hebt over documentatie, die heb ik wel. Heb alles netjes gedocumenteerd. Ook waarom nu graag met koppeltabellen zou willen werken etc. Maar voordat ik het zou gaan implementeren , zou ik graag ook de "andere" kant willen horen.

[zoepercavia]

Op zondag 09 juni 2002 13:45 schreef Otis het volgende:
Ut is niet zo moeilijk hoor. Je pakt een data modelleringstechniek, past de regels toe en uit je rollen-bollen diagram rolt een tabellenset. Ik snap die oeverloze discussies nooit omtrent 'is dit datamodel correct?' (en dan zien we een setje tabellen, maar geen model of data analyse resultaten die geleid hebben tot dat model)... Pas een modelleringstechniek toe en je bent klaar. Als je niet snapt wat een datamodelleringstechniek is: stay the f*ck away from databases.

Op welke modelleringstechnieken doel je dan? Gwoon database normalisatie of zijn er nog andere technieken voor beschikbaar?

[MF]

Op zondag 09 juni 2002 13:47 schreef blijhoofd_bennie het volgende:

[..]

Klopt, maar dan heeft een koppeltabel toch als voordeel dat het veel sneller werkt of kraam ik nu onzin uit?

Kort: JA
Lang: Ja, omdat het er maar net aan ligt waar je het voor gebruikt. Zoals ACM al zegt moet je wel elke keer bijwerken/toevoegen/verwijderen en dat kost ook tijd, het zal daarom zeker niet elke keer sneller zijn.

[whoami]

Het hangt allemaal af van de situatie, maar koppeltabellen gebruik ik toch enkel maar bij n op m relaties.

Als je ervan uitgaat dat een wagen maar tot één merk kan behoren en je maakt dan toch nog een koppeltabel (zodat n op m relaties in principe mogelijk zijn), dan komt dat toch niet duidelijk over in uw databank-model.
Ik vind dat je een goed zicht moet hebben op de relaties enzo door enkel een blik te werpen op het datamodel, zonder dat je daarbij extra documentatie voor hoeft te lezen. In het voorbeeld dat je dus aanhaalt, zou ik zeker geen koppeltabel gebruiken.

Door ook koppeltabellen te gaan gebruiken bij 1 op n relaties kun je wel argumenteren dat evt aanpassingen later makkelijker te implementeren zijn, maar als je een goede analyse gedaan hebt, zouden zo'n aanpassingen toch (meestal, er zijn altijd uitzonderingen) niet mogen voorkomen imho.

[blijhoofd_bennie]

Op zondag 09 juni 2002 14:07 schreef whoami het volgende:
Het hangt allemaal af van de situatie, maar koppeltabellen gebruik ik toch enkel maar bij n op m relaties.

Als je ervan uitgaat dat een wagen maar tot één merk kan behoren en je maakt dan toch nog een koppeltabel (zodat n op m relaties in principe mogelijk zijn), dan komt dat toch niet duidelijk over in uw databank-model.
Ik vind dat je een goed zicht moet hebben op de relaties enzo door enkel een blik te werpen op het datamodel, zonder dat je daarbij extra documentatie voor hoeft te lezen. In het voorbeeld dat je dus aanhaalt, zou ik zeker geen koppeltabel gebruiken.

Door ook koppeltabellen te gaan gebruiken bij 1 op n relaties kun je wel argumenteren dat evt aanpassingen later makkelijker te implementeren zijn, maar als je een goede analyse gedaan hebt, zouden zo'n aanpassingen toch (meestal, er zijn altijd uitzonderingen) niet mogen voorkomen imho.

Klopt normaal zou zo een aanpassing niet plaatsvinden. Maar een extra argument voor mij was dan de kans op fouten (dus pc loopt vast ofzo) op te vangen. Want als er bij mij wat mis kan gaan zou alleen de koppeling kapot gaan.
Maar ik zie verder wel in dat in mijn voorbeeld een koppeltabel iets te overdreven zou zijn (er zijn dingen aangekaart waar ik niet aan gedacht had)

[MF]

Op zondag 09 juni 2002 14:24 schreef blijhoofd_bennie het volgende:

[..]

Klopt normaal zou zo een aanpassing niet plaatsvinden. Maar een extra argument voor mij was dan de kans op fouten (dus pc loopt vast ofzo) op te vangen. Want als er bij mij wat mis kan gaan zou alleen de koppeling kapot gaan.
Maar ik zie verder wel in dat in mijn voorbeeld een koppeltabel iets te overdreven zou zijn (er zijn dingen aangekaart waar ik niet aan gedacht had)

Hoezo zou bij jouw alleen maar de koppeltabel kapot gaan dan?

[whoami]

Op zondag 09 juni 2002 14:24 schreef blijhoofd_bennie het volgende:


Maar een extra argument voor mij was dan de kans op fouten (dus pc loopt vast ofzo) op te vangen. Want als er bij mij wat mis kan gaan zou alleen de koppeling kapot gaan.

Als uw database transaction - logs bijhoudt, kun je na een crash ofzo toch altijd roll-backen naar de laatste juiste situatie.

[ACM]

Op zondag 09 juni 2002 14:24 schreef blijhoofd_bennie het volgende:
Want als er bij mij wat mis kan gaan zou alleen de koppeling kapot gaan.

Wie zegt dat dan niet alsnog je auto of merk tabel ook kapot gaan? Of dat er een onjuiste koppeling wordt gelegd?

Etc, de database is verantwoordelijk voor het consistent opslaan van de data.
Daar hoef jij je geen zorgen om te maken en daarom moet je ook zeker niet je model daarop proberen te ontwerpen.
Dat je zaken netjes in transacties verpakt is natuurlijk wat anders, maar met je tabelstructuur verbeter je dat echt niet mee hoor

[blijhoofd_bennie]

Op zondag 09 juni 2002 14:39 schreef whoami het volgende:

[..]

Als uw database transaction - logs bijhoudt, kun je na een crash ofzo toch altijd roll-backen naar de laatste juiste situatie.

Nu wordt nog access 2000 gebruikt en geen SQL (bij SQL zou ik zowieso gebruik maken van storedprocedures), maar volgens mij bied Access 2000 die mogelijkheid niet?

[blijhoofd_bennie]

Op zondag 09 juni 2002 14:41 schreef ACM het volgende:

[..]

Wie zegt dat dan niet alsnog je auto of merk tabel ook kapot gaan? Of dat er een onjuiste koppeling wordt gelegd?

Etc, de database is verantwoordelijk voor het consistent opslaan van de data.
Daar hoef jij je geen zorgen om te maken en daarom moet je ook zeker niet je model daarop proberen te ontwerpen.
Dat je zaken netjes in transacties verpakt is natuurlijk wat anders, maar met je tabelstructuur verbeter je dat echt niet mee hoor

Dit is dus gelijk het antwoordt op de vraag van misterfreeze.
Ik wilde m.b.v. mijn databasestructuur ook mogelijke fouten die gemaakt kunnen worden opvangen met mijn database structuur.
Wel jammer dat je het daarmee niet verbetert (maar ja als dat wel zo zou zijn zou de database niet helemaal 100% zijn geloof ik)

Maar ja you can't blame a guy for trying

Verdere reactie's zijn altijd welkom, maar heb nu wel een idee waar de problemen van mijn ideee zaten (de mogelijke nadelen van de andere manier had ik ja al opgesomt)
Nu de ideeen samenvoegen en mijn documentatie is degelijk zodat ik aan het werk kan.
Bedankt iedereen.

[Packardhell]

Je wilt dus gewoon relationele database zeker. Dat heeft wel z'n voordelen vooral consistentie is ook groot voordeel.

[ACM]

Op zondag 09 juni 2002 14:57 schreef Packardhell het volgende:
Je wilt dus gewoon relationele database zeker. Dat heeft wel z'n voordelen vooral consistentie is ook groot voordeel.

Euh ja, maar wat wil je daarmee zeggen?

Voorbeeld1 van hem is net zo goed relationeel (beter geloof ik zelfs, voor zover mogelijk) dan voorbeeld2.

[Verwijderd]

Ik heb de hele thread niet gelezen, maar volgens mij hangt het maar net van je ERD ontwerp af of je koppeltabellen moet gebruiken.

(n-n of 1-n relatie)

[blijhoofd_bennie]

Op zondag 09 juni 2002 15:11 schreef Tizzwat het volgende:
Ik heb de hele thread niet gelezen, maar volgens mij hangt het maar net van je ERD ontwerp af of je koppeltabellen moet gebruiken.

(n-n of 1-n relatie)

Kort samengevat: Het ging (gaat) om het feit of het verstandig is om altijd koppel tabellen te gebruiken ook al is er een 1:N relatie.

[Packardhell]

Op zondag 09 juni 2002 15:05 schreef ACM het volgende:

[..]

Euh ja, maar wat wil je daarmee zeggen?

Voorbeeld1 van hem is net zo goed relationeel (beter geloof ik zelfs, voor zover mogelijk) dan voorbeeld2.

Je hebt gelijk beetje loze opmerking. Koppeltabel is in het voorbeeld niet nodig vind ik. Meestal als je niet goed uitkomt kan je een koppeltabel gebruiken.

[The - DDD]

In een genormaliseerd diagram worden koppeltabellen alleen gebruikt voor n tot m relaties. Dus 0-n tegenover 0-m. In alle andere gevallen. 1-1 & 1-n is een koppeltabel overbodig. Soms doe je het wel, maar dan alleen om een hele goede reden. En het voorbeeld wat de topicstarter gaf is er geen. Ik kan zo niet even een voorbeeldje bedenken dat het wel nuttig zou zijn om "zinloos" koppeltabellen toe te passen, blijkt maar weer dat het in mijn ervaring erg weinig voor komt.

[Orphix]

Het gaat de topicstarter niet om het hoe en wanneer gebruik van koppeltabellen, maar hoe je het makkelijkst de gegevensintegriteit kan omzeilen ...
Een merk zou je nooit mogen verwijderen wanneer daar nog auto's aan hangen, ik zou geen geldig excuus kunnen verzinnen. Als je een merk verwijdert gooi dan ook de auto's weg. (Of zet die op een ander merk).

[Verwijderd]

Op zondag 09 juni 2002 15:24 schreef blijhoofd_bennie het volgende:

[..]

Kort samengevat: Het ging (gaat) om het feit of het verstandig is om altijd koppel tabellen te gebruiken ook al is er een 1:N relatie.

Indien je een modelleringstechniek gebruikt die resulteert in een 3e normaalvorm tabellenstructuur dan is deze vraag dom: ja, altijd koppeltabellen gebruiken, want ze resulteren uit je model.

Zoals ik al zei: als je niet weet wat een modelleringstechniek is, stay away from databases.

[edit]
Je moet niet in tabellen denken maar in entiteiten en relaties tussen die entiteiten, met daarop weer constraints. Zodra je in tabellen gaat denken ben je verloren en ga je focussen op details die normaliter uit je model (entiteiten+relaties+constraints) volgen, maar die je nu moet invullen op basis van intuitie. Vandaar dat je altijd een modelleringstechniek MOET gebruiken, en niet uit de losse pols je tabellen moet gaan creeeren. Dan krijg je nl. de vragen die jij stelt als topicstart. Een goede modelleringstechniek is NIAM of daarvan afgeleid: ORM. Deze techniek focussed niet op tabellen maar louter op entiteiten, relaties en constraints en door de methodiek om van model naar tabel + constaints te komen resulteert het altijd in een correcte tabelset + constraints. Gebruiken dus.

[blijhoofd_bennie]

Op zondag 09 juni 2002 18:48 schreef Otis het volgende:

[..]

Indien je een modelleringstechniek gebruikt die resulteert in een 3e normaalvorm tabellenstructuur dan is deze vraag dom: ja, altijd koppeltabellen gebruiken, want ze resulteren uit je model.

Zoals ik al zei: als je niet weet wat een modelleringstechniek is, stay away from databases.

[edit]
Je moet niet in tabellen denken maar in entiteiten en relaties tussen die entiteiten, met daarop weer constraints. Zodra je in tabellen gaat denken ben je verloren en ga je focussen op details die normaliter uit je model (entiteiten+relaties+constraints) volgen, maar die je nu moet invullen op basis van intuitie. Vandaar dat je altijd een modelleringstechniek MOET gebruiken, en niet uit de losse pols je tabellen moet gaan creeeren. Dan krijg je nl. de vragen die jij stelt als topicstart. Een goede modelleringstechniek is NIAM of daarvan afgeleid: ORM. Deze techniek focussed niet op tabellen maar louter op entiteiten, relaties en constraints en door de methodiek om van model naar tabel + constaints te komen resulteert het altijd in een correcte tabelset + constraints. Gebruiken dus.

Volgens jij geloof jij juist teveel in die modelerings technieken. En het is mij ook wel redelijk duidelijk dat als er geen N:M relatie is dat het misschien handig zou zijn om geen koppeltabel te gebruiken.

En voor the record ik heb ook zo'n schema getekend, met alle entiteiten (ik noem ze persoonlijk liever hoofdgroepen, klinkt toch wat duidelijker) En dan kwamen de "gewenste" gangbare situatie er uit (dus niet koppeltabel te gebruiken zoals jij in jou reactie aanhaalt).

Maar ik (zo eigenwijs als ik ben) geloof niet altijd alles wat een schema me zegt. Ik zoek ook naar andere manieren en de mogelijke voordelen/nadelen daaraan, voordat ik echt voor een bepaald systeem kies. Noem het gek maar zo is denk ik er nu eenmaal over.

Tevens praat jij over en modulerings techniek, ik zou ook wel eens willen weten welke je gebruikt, aangezien er toch wat verschillende zijn? (waarbij het resultaat normaal wel altijd hetzelfde moet zijn)

[Verwijderd]

Ik zeg toch nee tegen koppeltabellen, altijd Id (autonummering) meenemen naar andere table. Met koppelen naar andere databases krijg je anders de kans dat je Id`s handmatig moet koppellen met andere ID`s.
eeh ja, mischien niemand die dit snapt, ken het niet beter uitleggen.

[Verwijderd]

Op zondag 09 juni 2002 23:35 schreef blijhoofd_bennie het volgende:
[..]
Volgens jij geloof jij juist teveel in die modelerings technieken. En het is mij ook wel redelijk duidelijk dat als er geen N:M relatie is dat het misschien handig zou zijn om geen koppeltabel te gebruiken.

*zucht*, je snapt er volgens mij echt heel erg weinig van. Er IS geen andere weg dan met een model te starten en daarmee je tabellen te bepalen. Iedere tabelset die is ontstaan uit de losse pols zonder model is pas correct als je een model kunt tekenen dat precies die tabellen oplevert. PLUS is de tabelset alleen uitbreidbaar door het model aan te passen en niet uit de losse pols maar wat tabellen.

Dus als ik geloof in modelleringstechnieken: ja. Waarom? Omdat dat de enige juiste weg is om een tabelset te bepalen.

En voor the record ik heb ook zo'n schema getekend, met alle entiteiten (ik noem ze persoonlijk liever hoofdgroepen, klinkt toch wat duidelijker) En dan kwamen de "gewenste" gangbare situatie er uit (dus niet koppeltabel te gebruiken zoals jij in jou reactie aanhaalt).

De 'gewenste' situatie weet je niet, want je gaat er dan bij voorbaat vanuit dat, kijkend naar de analyse resultaten, de tabellen die je DENKT nodig te hebben, de juiste zijn. DE standaardfout die gemaakt wordt door veel mensen die denken iets van databases te snappen. Ze tekenen dan soms nog wel een model maar doen dat op zo'n manier dat het model precies oplevert hetgeen ze willen. Maar zo werkt het niet.

En die dingen heten entiteiten. Ze anders noemen levert interpretatie-fouten op bij het lezen van publicaties op dit gebied.

Dat jij een gewenste situatie eruit krijgt zonder koppeltabel bij een n:m relatie is fijn voor je. Ik hoop voor je dat je niet hier over een weekje of wat vragen moet gaan stellen hoe je de queries moet gaan bouwen om je tabelset overeind te houden.

Maar ik (zo eigenwijs als ik ben) geloof niet altijd alles wat een schema me zegt. Ik zoek ook naar andere manieren en de mogelijke voordelen/nadelen daaraan, voordat ik echt voor een bepaald systeem kies. Noem het gek maar zo is denk ik er nu eenmaal over.

Your loss. Eigenwijsheid gekoppeld aan onwetendheid is killing. Neem eens iets aan van iemand die al 10 jaar datamodellen maakt, en wellicht leer je er iets van waar je wat aan hebt, ipv eigenwijs door gaat modderen.

Je focus op details aan het eind van het traject ipv de details aan het begin van het traject geeft aan dat je halverwege het traject begint ipv aan het begin en daarmee ook aangeeft dat er kennis ontbreekt. Hou jezelf niet voor de gek en maak het jezelf niet te moeilijk, maar absorbeer kennis en pas die toe ipv je af te sluiten voor kennis die je krijgt toegeworpen.

Wil je nadelen weten van modelleren van analysegegevens? Wil je nadelen weten van normaliseren? Open een thread en ik geef je een hele waslijst. Ik heb echter in de loop der jaren ook alle nadelen van ongenormaliseerd gebroddel wel gezien in allerlei vormen, wat dan werd goedgepraat door de desbetreffende knoeier met de meest fantastische smoesen, en ik weet totaan mijn laatste vezel dat modelleren en normaliseren, ongeacht hun nadelen, essentieel zijn voor een goed resultaat voor nu en in de toekomst.

Tevens praat jij over en modulerings techniek, ik zou ook wel eens willen weten welke je gebruikt, aangezien er toch wat verschillende zijn? (waarbij het resultaat normaal wel altijd hetzelfde moet zijn)

Ik gebruik NIAM op papier en ORM middels een case tool. Ze zijn aan elkaar gerelateerd dus omschakelen is niet zo'n probleem.

Ik verafschuw 'modelleringstechnieken' als E/R model, omdat die 1:1 afbeeldbaar zijn op tabellen + constraints, terwijl het juist gaat om die abstractie van entiteiten + relaties + constraints, waardoor je bv door het toevoegen van 1 entiteit en 2 relaties meer tabellen krijgt dan je verwacht. (om over objectified relations nog maar te zwijgen)

[Verwijderd]

Kijk, daar hebben we nog eens wat aan, GO OTIS!

[dusty]

en ik weet totaan mijn laatste vezel dat modelleren en normaliseren, ongeacht hun nadelen, essentieel zijn voor een goed resultaat voor nu en in de toekomst.

Helaas normaliseren heel veel mensen niet correct, ze gaan ALTIJD door naar de 3e normaalsvorm ongeacht de omstandigheden. teveel mensen gaan of te ver of niet ver genoeg met normaliseren.

Ik sta trouwens volledig achter Otis' post.

[Verwijderd]

Op zondag 09 juni 2002 13:24 schreef blijhoofd_bennie het volgende:
Ik een heel erge voorstander van koppeltabellen. Ook als deze niet direct nodig zijn. De reden waarom zal ik proberen uit te leggen aan de hand van een voorbeeld wat me zo te binnen schiet.

Voorbeeld 1:
Je verkoopt auto's en je wilt wat gegevens in een database opslaan. We slaan voor het gemak maar 2 dingen op, de naam van de auto en het merk.

Een database ontwerp zou kunnen zijn:

Merk (tabel)

MerkID
MerkNaam

Auto (tabel):
AutoID
AutoNaam
MerkID

In dit geval heeft de tabel merk een relatie met de tabel auto d.m.v. het MerkID. Dit kan in dit geval perfect omdat een auto maar 1 merk kan hebben. Het nadeel wat hier (volgens mij) aanzit is het volgende. Als ik een merk verwijderd kan dit niet, doordat er een relatie zit tussen de twee tabellen. Zou ik dan toch een merk willen verwijderen zou ik ook een auto moeten verwijderen (of het ID veld leeglaten en/of ander merk kiezen). Maar dit willen we niet. Ook al zijn er geen merken meer, de gegevens van de auto moeten beschikbaar blijven.

Dit kan niet, aangezien er een constraint is geplaatst tussen Merk en Auto en wel een 'relatie': er is een relatie gedefinieerd tussen Merk en Auto, en wel een 1:n relatie:

[Merk] belongs to [Auto]/[Auto] has [Merk]

Haal je die relatie weg, dan kun je alle merken verwijderen zonder auto rows te verwijderen, maar dat zou je model waardeloos maken. Ergo: die relatie bestaat en resulteert in een FK constraint in de Auto tabel naar de Merken tabel. Die FK is er om de data in de tabelset correct volgens het model te laten zijn. Wat jij dus wilt is onzin.

Voorbeeld 2 (zo zou ik het doen)

Merk (tabel)

MerkID
MerkNaam

Auto (tabel):
AutoID
AutoNaam

AutoMerk (koppeltabel)
AutoMerkID
AutoID
MerkID

Dit heet een objectified relation: een relatie tussen meerdere entiteiten ga je weer zien als een entiteit waardoor je de relatie tussen entiteiten weer kunt gebruiken in andere relaties. Bv in een bugtracker database kun je definieren dat een zeker project met een zeker versienummer en een zeker buildnummer een bug heeft. Door de relatie tussen project, versienummer en buildnummer te objectifyen kun je makkelijker daar een relatie mee leggen met 'bug'.

Dit wordt echter bijna altijd alleen gedaan wanneer er 3 of meerdere entiteiten tezamen 1 relatie vormen. In jouw geval is dat a) niet nodig omdat het een 1:n relatie betreft en b) niet nodig omdat de relatie Auto - Merk niet gebruikt gaat worden in andere relaties: je kunt t.a.t. 'Merk' achterhalen door naar Auto te kijken, waardoor je 'Merk' niet hoeft op te nemen in een relatie tussen een 3e entiteit en Auto - Merk.

Sommige database-otwerpers kiezen altijd voor een objectified relation bij 2 of meerdere entiteiten in een relatie ipv 3 of meer, zodat ze gemakkelijker op database niveau kunnen werken met een zeker record (dus een zekere relatie tussen twee rows in twee tabellen). Ikzelf vind objectified relations alleen nodig indien je de koppeling tussen entiteiten middels een relatie gebruikt als unieke entiteit in een andere relatie. (zoals hierboven met [project - versienummer - buildnummer] - [bug]) Objectification is dan gerechtvaardigd omdat je alle waarden van de entiteiten nodig hebt om 1 unieke waarde aan te geven waar de relatie met de waarde van de entiteit uit de gerelateerde tabel specifiek voor geldt. In jouw situatie absoluut niet het geval.

De voordelen ten opzicht van voorbeeld 1 zijn wel duidelijk. Er wordt alleen een koppeling tussen de tabellen gemaakt. Als er in dit geval dus een merk zou verdwijnen zouden de gegevens over de auto in ieder geval blijven bestaan.

Nee! In jouw simplistische situatie kun je niet een row uit de Merkentabel verwijderen indien er relaties liggen tussen waarden in die tabel en rows in de Autos tabel, ivm de relatie die is gedefinieerd tussen die tabellen, immers een auto heeft ALTIJD een merk, of dat nu bestaat of niet, het is een mandatory relation! Je zult dus de Merkentabel moeten uitbreiden met attributen die aangeven of het merk nog bestaat of niet. (of iets dergelijks)

Ook zou ik in dit geval meerdere merken aan 1 auto kunnen koppelen (als dit van toepassing mocht zijn natuurlijk).

Je loopt te knoeien. OF je relatie is n:m, OF je relatie is 1:1 OF je relatie is 1:n. In je model de relatie veranderen KAN nieuwe tabellen opleveren, maar hoeft niet. Als je bij voorbaat stelt dat een relatie 1:n is, dan resulteert dat hier in een 2 tabel-structuur met een FK in de Auto tabel. Verander je dat later, dan veranderen je tabellen. ALLEEN DAN, niet eerder, niet later. Als jij nu een n:m tabellenstructuur definieert terwijl het een 1:n madatory relation is, non objectified, dan is je tabellenset fout, want deze komt niet overeen met je model (waarin de relatie 1:n mandatory non objectified is gedefinieerd).

Een ander voordeel is dat het op deze manier veel meer uitbreid mogelijkheden heeft.

Tabellensets breid je niet uit. Modellen breid je uit. Daaruit volgt dan een nieuwe tabellenset en DAARNA pas kijk je of je iets moet wijzigen of iets moet creeeren. Jij gaat je model al voorzien van n:m relaties op plaatsen waar 1:n relaties zijn gedefinieerd want 'wat niet is kan komen'. Tja, waarom stop je dan nog attributen bij elkaar in 1 tabel? Stel je voor dat ze ipv een 1:1 relatie met de PK een n:m relatie met de PK krijgen!

Ergo: kijk naar je model, wijzig dat, kijk dan naar de nieuwe tabellenset en kijk dan wat is gewijzigd. Niet andersom doen, want je wijzigigen zijn dan 1) foutief en 2) nergens op gebaseerd!

[Verwijderd]

Op maandag 10 juni 2002 10:06 schreef dusty het volgende:
[..]
Helaas normaliseren heel veel mensen niet correct, ze gaan ALTIJD door naar de 3e normaalsvorm ongeacht de omstandigheden. teveel mensen gaan of te ver of niet ver genoeg met normaliseren.

Het leuke is dat bijna iedere modelleringstechniek iig 3e normaalvorm oplevert. Dus zonder dat je iets extra's doet krijg je een uitgenormaliseerd model.

Normaliseren is niet altijd nodig, klopt. Het is een compromis tussen weinig moeite in updaten van data (doordat er weinig redundancy in zit) vs. veel moeite in het bijelkaar schrapen van data middels joins. Wanneer je erg veel joins moet doen elke keer kun je besluiten een normaalvorm terug te gaan waardoor je wel redundancy introduceert maar je programmatuur efficienter maakt op bepaalde punten (en minder efficient op andere punten, nl. de updates).

Ikzelf ga nooit verder dan de 3e normaalvorm omdat ik het nut van de 4e en 5e niet echt inzie (ivm de complexiteit van de dataretrieval code). Maar er zijn uiteraard situaties te bedenken waarbij ze nodig zijn en juist erg efficient kunnen zijn.

[Arnout]

Otis schreef:
Ik verafschuw 'modelleringstechnieken' als E/R model, omdat die 1:1 afbeeldbaar zijn op tabellen + constraints, terwijl het juist gaat om die abstractie van entiteiten + relaties + constraints, waardoor je bv door het toevoegen van 1 entiteit en 2 relaties meer tabellen krijgt dan je verwacht. (om over objectified relations nog maar te zwijgen)

Je moest eens weten hoeveel opleidingen dit als de 'default' modelleringstechniek aanbieden.

[TheDjasp]

* TheDjasp wil zich na het lezen van deze thread meer weten over NIAM & ORM en vraagt zich af wat een goede plek is om te beginnen (boek/site).

[Verwijderd]

Op maandag 10 juni 2002 10:37 schreef TheDjasp het volgende:
* TheDjasp wil zich na het lezen van deze thread meer weten over NIAM & ORM en vraagt zich af wat een goede plek is om te beginnen (boek/site).

Knock yourself out: http://www.orm.net/

Erg veel PDF's en info om te lezen.

NIAM: er zijn veel publicaties omtrent NIAM geweest, waaronder veel boeken van o.a. Nijssen. Ik heb zelf het boek Conceptual Schema and Relational Database Design van G.M. Nijssen en T.A. Halpin (ISBN 0-7248-0151-0). Dit is wel al vrij oud *cough* en nadien is NIAM aangepast door verschillende mensen, waaronder Nijssen zelf. Ik vind het boek zelf niet om door te komen, dus als je een ander boek kunt vinden omtrent NIAM, dan zou ik het zeker proberen. Maar http://www.orm.net/ bevat aardig wat referenties naar NIAM en zaken omtrent NIAM dus wellicht dat je daar de nodige boektitels kunt opduiken en middels amazone.com de beste eruit kunt halen.

(ook het Conceptual Query stuk op orm.net is zeer interessant en legt goed de problemen bloot mbt de huidige generatie RDBMS'en)

[blijhoofd_bennie]

Op maandag 10 juni 2002 09:49 schreef Otis het volgende:

[..]

*zucht*, je snapt er volgens mij echt heel erg weinig van. Er IS geen andere weg dan met een model te starten en daarmee je tabellen te bepalen. Iedere tabelset die is ontstaan uit de losse pols zonder model is pas correct als je een model kunt tekenen dat precies die tabellen oplevert. PLUS is de tabelset alleen uitbreidbaar door het model aan te passen en niet uit de losse pols maar wat tabellen.

Dus als ik geloof in modelleringstechnieken: ja. Waarom? Omdat dat de enige juiste weg is om een tabelset te bepalen.
[..]

De 'gewenste' situatie weet je niet, want je gaat er dan bij voorbaat vanuit dat, kijkend naar de analyse resultaten, de tabellen die je DENKT nodig te hebben, de juiste zijn. DE standaardfout die gemaakt wordt door veel mensen die denken iets van databases te snappen. Ze tekenen dan soms nog wel een model maar doen dat op zo'n manier dat het model precies oplevert hetgeen ze willen. Maar zo werkt het niet.

En die dingen heten entiteiten. Ze anders noemen levert interpretatie-fouten op bij het lezen van publicaties op dit gebied.

Dat jij een gewenste situatie eruit krijgt zonder koppeltabel bij een n:m relatie is fijn voor je. Ik hoop voor je dat je niet hier over een weekje of wat vragen moet gaan stellen hoe je de queries moet gaan bouwen om je tabelset overeind te houden.

[..]

Your loss. Eigenwijsheid gekoppeld aan onwetendheid is killing. Neem eens iets aan van iemand die al 10 jaar datamodellen maakt, en wellicht leer je er iets van waar je wat aan hebt, ipv eigenwijs door gaat modderen.

Je focus op details aan het eind van het traject ipv de details aan het begin van het traject geeft aan dat je halverwege het traject begint ipv aan het begin en daarmee ook aangeeft dat er kennis ontbreekt. Hou jezelf niet voor de gek en maak het jezelf niet te moeilijk, maar absorbeer kennis en pas die toe ipv je af te sluiten voor kennis die je krijgt toegeworpen.

Wil je nadelen weten van modelleren van analysegegevens? Wil je nadelen weten van normaliseren? Open een thread en ik geef je een hele waslijst. Ik heb echter in de loop der jaren ook alle nadelen van ongenormaliseerd gebroddel wel gezien in allerlei vormen, wat dan werd goedgepraat door de desbetreffende knoeier met de meest fantastische smoesen, en ik weet totaan mijn laatste vezel dat modelleren en normaliseren, ongeacht hun nadelen, essentieel zijn voor een goed resultaat voor nu en in de toekomst.
[..]

Ik gebruik NIAM op papier en ORM middels een case tool. Ze zijn aan elkaar gerelateerd dus omschakelen is niet zo'n probleem.

Ik verafschuw 'modelleringstechnieken' als E/R model, omdat die 1:1 afbeeldbaar zijn op tabellen + constraints, terwijl het juist gaat om die abstractie van entiteiten + relaties + constraints, waardoor je bv door het toevoegen van 1 entiteit en 2 relaties meer tabellen krijgt dan je verwacht. (om over objectified relations nog maar te zwijgen)

Op de ik weet het beter antwoorden (volgens mij) antwoord ik niet eens op.
Ik geloof dat jij mijn stelling niet begrijpt, modulerings technieken zijn heel goed, maar je hoeft niet altijd bij het resultaat te zweren, dat bedoel ik te zeggen (je moet altijd zoeken naar "misschien" betere manieren, ook al komt het er niet van)

No offence, maar jij hoort (denk ik) bij het volk die alles goedkeuren wat veel mensen als goedgekeurd vinden. Maar zo ben ik dus niet (ok noem het maar eigenwijs). Ik zoek dus altijd naar "mogelijke" manieren. Ik wil gewoon het hele verhaal horen en niet een "deel" wat een ontwerp mij "zegt".

En ff over de benaming duh ik weet ook dat het entiteiten zijn en al die andere namen ook (heb ook boeken ). En de documentatie die ik maak is eerst voor mezelf en dan vind ik entiteiten gewoon niet een correct woord op dat moment (dat heb ik wel bij meerdere termen). Bij de officieele documentatie die ik dan uiteindelijk samenstel, neem ik wel de juiste benaming (zodat het voor iedereen duidelijk is). Is misschien omslachtig ja, maar ik documenteer het eerst zo dat ik alles op een rijtje heb en voor mij snel werkt i.p.v. direct voor "iedereen" te schrijven.

En het antwoordt over dat ik de situatie ken, tuurlijk ken ik die? Ik weet niet hoe jij DB's ontwerpt, maar je kunt niets ontwerpen totdat je informatie hebt verzameld over de onderwerpen. Hoe wil jij anders een db ontwerpen? Je gaat dus eerst kijken waar is het belangrijk voor... een auto bedrijf (terugkomend op mijn voorbeeld) en dan schrijf je de hoofdgroepen (entiteiten) op die van belang kunnen zijn (in overleg met klant)
Vervolgens maak je daar een relatieschema van. En zoals volgens mij wel duidelijk was, had ik die fase al gehad.

De volgende stap is dan het gedetaileerd verzamelen van gegevens (dus mogelijke velden bepalen). Als je de velden allemaal denkt te hebben ga je bezig met het functionele ontwerp van het programma (dus de omgeving waar de gebruiker mee werkt) want als je eerst de db maakt en dan het programma, kan het voorkomen dat de db ontwerper (jij dus) een onmogelijke situatie creeert voor de programmeur.
En als de programmeur het functionele ontwerp en de schermen af heeft (in overleg met het db natuurlijk). Gaat de database ontwerper de db maken en de programmeur het programma.

[blijhoofd_bennie]

Op maandag 10 juni 2002 10:20 schreef Otis het volgende:

[..]

Dit kan niet, aangezien er een constraint is geplaatst tussen Merk en Auto en wel een 'relatie': er is een relatie gedefinieerd tussen Merk en Auto, en wel een 1:n relatie:

[Merk] belongs to [Auto]/[Auto] has [Merk]

Haal je die relatie weg, dan kun je alle merken verwijderen zonder auto rows te verwijderen, maar dat zou je model waardeloos maken. Ergo: die relatie bestaat en resulteert in een FK constraint in de Auto tabel naar de Merken tabel. Die FK is er om de data in de tabelset correct volgens het model te laten zijn. Wat jij dus wilt is onzin.
[..]

Dit heet een objectified relation: een relatie tussen meerdere entiteiten ga je weer zien als een entiteit waardoor je de relatie tussen entiteiten weer kunt gebruiken in andere relaties. Bv in een bugtracker database kun je definieren dat een zeker project met een zeker versienummer en een zeker buildnummer een bug heeft. Door de relatie tussen project, versienummer en buildnummer te objectifyen kun je makkelijker daar een relatie mee leggen met 'bug'.

Dit wordt echter bijna altijd alleen gedaan wanneer er 3 of meerdere entiteiten tezamen 1 relatie vormen. In jouw geval is dat a) niet nodig omdat het een 1:n relatie betreft en b) niet nodig omdat de relatie Auto - Merk niet gebruikt gaat worden in andere relaties: je kunt t.a.t. 'Merk' achterhalen door naar Auto te kijken, waardoor je 'Merk' niet hoeft op te nemen in een relatie tussen een 3e entiteit en Auto - Merk.

Sommige database-otwerpers kiezen altijd voor een objectified relation bij 2 of meerdere entiteiten in een relatie ipv 3 of meer, zodat ze gemakkelijker op database niveau kunnen werken met een zeker record (dus een zekere relatie tussen twee rows in twee tabellen). Ikzelf vind objectified relations alleen nodig indien je de koppeling tussen entiteiten middels een relatie gebruikt als unieke entiteit in een andere relatie. (zoals hierboven met [project - versienummer - buildnummer] - [bug]) Objectification is dan gerechtvaardigd omdat je alle waarden van de entiteiten nodig hebt om 1 unieke waarde aan te geven waar de relatie met de waarde van de entiteit uit de gerelateerde tabel specifiek voor geldt. In jouw situatie absoluut niet het geval.
[..]

Nee! In jouw simplistische situatie kun je niet een row uit de Merkentabel verwijderen indien er relaties liggen tussen waarden in die tabel en rows in de Autos tabel, ivm de relatie die is gedefinieerd tussen die tabellen, immers een auto heeft ALTIJD een merk, of dat nu bestaat of niet, het is een mandatory relation! Je zult dus de Merkentabel moeten uitbreiden met attributen die aangeven of het merk nog bestaat of niet. (of iets dergelijks)
[..]

Je loopt te knoeien. OF je relatie is n:m, OF je relatie is 1:1 OF je relatie is 1:n. In je model de relatie veranderen KAN nieuwe tabellen opleveren, maar hoeft niet. Als je bij voorbaat stelt dat een relatie 1:n is, dan resulteert dat hier in een 2 tabel-structuur met een FK in de Auto tabel. Verander je dat later, dan veranderen je tabellen. ALLEEN DAN, niet eerder, niet later. Als jij nu een n:m tabellenstructuur definieert terwijl het een 1:n madatory relation is, non objectified, dan is je tabellenset fout, want deze komt niet overeen met je model (waarin de relatie 1:n mandatory non objectified is gedefinieerd).
[..]

Tabellensets breid je niet uit. Modellen breid je uit. Daaruit volgt dan een nieuwe tabellenset en DAARNA pas kijk je of je iets moet wijzigen of iets moet creeeren. Jij gaat je model al voorzien van n:m relaties op plaatsen waar 1:n relaties zijn gedefinieerd want 'wat niet is kan komen'. Tja, waarom stop je dan nog attributen bij elkaar in 1 tabel? Stel je voor dat ze ipv een 1:1 relatie met de PK een n:m relatie met de PK krijgen!

Ergo: kijk naar je model, wijzig dat, kijk dan naar de nieuwe tabellenset en kijk dan wat is gewijzigd. Niet andersom doen, want je wijzigigen zijn dan 1) foutief en 2) nergens op gebaseerd!

Ik waardeer jou "opbeurende kritiek" wel, maar je vertelt me dingen die ik wel weet (misschien nog niet zo goed als jou, maar jou gegevens zijn mij duidelijk).
Ik weet dat dit een 1:N relatie is dus geen koppeltabel nodig is.
Maar IK (ja ik) stel d.m.v. mijn manier de gegevens in de database voorop. En dus niet de direct de relatie's tussen de gegevens. En dit is dan puur voor the worst case senario en omdat naar mijn mening de gegevens altijd als eerst behouden moeten blijven en niet de relatie's.

Kleine uitleg van mijn gedachten gang:

Een auto heeft een "merk" maar de gegevens van de auto zijn niet "direct" afhankelijk van een merk. Bijvoorbeeld een motor van fiat en opel (of welk merk dan ook) zijn misschien anders, maar een motor blijft een motor.

Ik probeer dus gewoon de gegevens appart te houden van de relatie's. Is hier een benaming voor?

Modellen breidt je uit ja, maar doordat er 1 (of meerdere) entiteit later (2 maanden/weken bijvoorbeeld) kan dit erge gevolgen hebben voor de tabellensets/programma, dus hier moet wel rekening mee gehouden worden voor zover mogelijk (en als dat punt van de ontwerp fase bereikt is natuurlijk).

[Verwijderd]

Ik voorspel je een harde klap tegen de muur. Wellicht niet nu maar zeker in de nabije toekomst. Het negeren van bewezen methodieken is al niet echt slim, het met opzet foutief opzetten van een tabellenset is helemaal niet slim. Nu is het een 2 a 3 tabellensetje. Bij een database met meer dan 100 tabellen en een model met meerdere lagen en een veelvoud aan pagina's kom jij er niet meer uit met je 'ik-voel-het-aan-mn-theewater-hier-moet-een-koppeltabel'-methode.

Veel broddelplezier nog.

[Gerco]

Ik kan getuigen van de *evil* van de broddelmethode. Hier op mn werk werken we met een 'databaseje' met een tabelletje of 800.

Er is geen enkel model in de organisatie, als iemand iets op moet slaan waar nog geen tabel voor is, maakt 'ie er gewoon 1 aan. Er is geen enkele naming convention, ongeschreven regels of wat dan ook.

Dit resulteert in een GIGANTISCHE teringzooi waarbij NIEMAND weet wat waarvoor dient of waar 'ie wat moet opzoeken. Er zitten ook zeker een 200 ofzo (inmiddels) ongebruikte tabellen in de database, maar omdat er nergens is gedocumenteerd wat welke tabellen waarvoor gebruikt, weet niemand welke dat zijn.

We zijn inmiddels aan een inventarisatie en opruim actie begonnen, maar het einde is voorlopig niet in zicht. Het zal waarchijnlijk minimaal een jaar duren voordat in kaart is gebracht hoe de database er NU uitziet. Dan moeten we nog nadenken over wat we eraan gaan doen...

Vreemd genoeg staat het pakket goed in de markt en verkoopt het als een trein

[ACM]

Op dinsdag 11 juni 2002 09:41 schreef Gerco het volgende:
Het zal waarchijnlijk minimaal een jaar duren voordat in kaart is gebracht hoe de database er NU uitziet.

Ik wilde je al vragen 'ben je daar nog niet mee klaar dan?'

Maar goed, de interne werking van een pakket bepaald absoluut niet hoe goed het verkoopt, vergelijk maar met het succes van vhs en windows (sorry, kon het niet laten )

[Gerco]

Op dinsdag 11 juni 2002 09:44 schreef ACM het volgende:
Maar goed, de interne werking van een pakket bepaald absoluut niet hoe goed het verkoopt, vergelijk maar met het succes van vhs en windows (sorry, kon het niet laten )

Daar zit wat in...

_{Gelukkig ziet mn baas niet dat ik zulke dingen schrijf, ik denk niet dat 'ie er blij mee zou zijn als ik aan iedereen vertel dat zn pakket aan alle kanten rammelt (ook al weet 'ie het zelf net zo goed).}

* Gerco gaat bijlezen over ORM. E/R heb ik altijd al een beetje onzin gevonden, alleen waren ze het daar op de TU niet echt mee eens

[ACM]

Op dinsdag 11 juni 2002 09:46 schreef Gerco het volgende:
_{Gelukkig ziet mn baas niet dat ik zulke dingen schrijf, ik denk niet dat 'ie er blij mee zou zijn als ik aan iedereen vertel dat zn pakket aan alle kanten rammelt (ook al weet 'ie het zelf net zo goed).}

Daar is het een baas voor

Zolang je de naam niet noemt valt het nog wel wat mee

[Verwijderd]

Op dinsdag 11 juni 2002 09:41 schreef Gerco het volgende:
Ik kan getuigen van de *evil* van de broddelmethode. Hier op mn werk werken we met een 'databaseje' met een tabelletje of 800.
Er is geen enkel model in de organisatie, als iemand iets op moet slaan waar nog geen tabel voor is, maakt 'ie er gewoon 1 aan. Er is geen enkele naming convention, ongeschreven regels of wat dan ook.
Dit resulteert in een GIGANTISCHE teringzooi waarbij NIEMAND weet wat waarvoor dient of waar 'ie wat moet opzoeken. Er zitten ook zeker een 200 ofzo (inmiddels) ongebruikte tabellen in de database, maar omdat er nergens is gedocumenteerd wat welke tabellen waarvoor gebruikt, weet niemand welke dat zijn.

[...]

Vreemd genoeg staat het pakket goed in de markt en verkoopt het als een trein

Exact Software ?

Jouw horror-story komt me bekend voor. Mijn loopbaan ben ik begonnen bij Triple-p transport systems waar we werkten aan RoadRunner, een compleet pakket voor de transportbranche. Ook iets van 500+ tabellen. Alles in een 4GL taal gebakken door mensen zonder opleiding en er was _GEEN_ documentatie ("Vraag Wim maar, die weet het wel") noch een model. We werkten ook nog met uniVerse, een database die 3D tabellen toestaat (dus in een veld kun je weer een tabel hebben, nou daar wisten ze wel raad mee *aaaaaarg*). Toen ik van ellende toch maar begon met het in kaart brengen van de puinbak en wijzigingen middels een model wilde doorvoeren stuitte ik op verzet van zowel management als collega's. Echt bizar. Het pakket bestaat overigens nog steeds, bij gebrek aan beter, maar heeft zn glans wel verloren. Het kostte de klanten ook zeer veel geld om wijzigingen door te laten voeren omdat het systeem botweg niet uit te breiden was, want niemand wist, behalve Wim in de hoek van de kamer, hoe alles werkte. De rest plakte her en der maar velden bij of erger: stopte tabellen in velden binnen inmense andere tabellen.

Echt bizar hoe sommige mensen denken hoe je software moet bouwen.

[Gerco]

Op dinsdag 11 juni 2002 10:44 schreef Otis het volgende:
Exact Software ?

^{BINGO! (nog 4GL ook)}

[verhaal over 3D tabellen]

AAAAARRRRRGGGGGHHHHHH!!!!!!

Dat verhaal over Wim in de hoek ken ik ook ja, alleen heet 'ie hier anders

[Crazy D]

Op dinsdag 11 juni 2002 10:47 schreef Gerco het volgende:
^{BINGO! (nog 4GL ook)}

Ik herinner me de kreet nog bij de presentatie vorig jaar dat het alleen maar minder tabellen zouden worden... voorlopig zijn het er alleen maar meer geworden

Veel sterkte...

[Gerco]

Op dinsdag 11 juni 2002 11:08 schreef Crazy_D het volgende:
Ik herinner me de kreet nog bij de presentatie vorig jaar dat het alleen maar minder tabellen zouden worden... voorlopig zijn het er alleen maar meer geworden

Daar weet ik allemaal niets van. Ik werk bij een bedrijfnr binnen Exact Groep, niet bij Exact Software zelf (al heb ik wel een @exactsoftware.com e-mail adres).

[Crazy D]

Op dinsdag 11 juni 2002 11:24 schreef Gerco het volgende:
Daar weet ik allemaal niets van. Ik werk bij een bedrijfnr binnen Exact Groep, niet bij Exact Software zelf (al heb ik wel een @exactsoftware.com e-mail adres).

Geluksvogel Waar werk je dan aan, als ik vragen mag? (gaat wel wat offtopic geloof ik...)

[whoami]

Op dinsdag 11 juni 2002 11:47 schreef Crazy_D het volgende:
(gaat wel wat offtopic geloof ik...)

Ja, idd. Misschien kunnen jullie die conversatie verder zetten via mail/irc/watdanook. GoT is niet echt een chatbox...

[Gerco]

Op dinsdag 11 juni 2002 11:47 schreef Crazy_D het volgende:
Geluksvogel Waar werk je dan aan, als ik vragen mag? (gaat wel wat offtopic geloof ik...)

Dat mag je best vragen, maar ik geloof dat er in het pand meer tweakers aanwezig zijn. En in het licht van mn eerdere opmerking over de "programmastructuur" lijkt het me niet verstandig dat zomaar te zeggen

PS. [e-mail]

[Crazy D]

Op dinsdag 11 juni 2002 11:49 schreef Gerco het volgende:
Dat mag je best vragen, maar ik geloof dat er in het pand meer tweakers aanwezig zijn. En in het licht van mn eerdere opmerking over de "programmastructuur" lijkt het me niet verstandig dat zomaar te zeggen

Zelfs Eduard zal toch wel weten dat het een zooitje is? (hoewel de meesten het niet rechtstreeks zullen zeggen ("ja het is idd een klerezooitje") heb ik van verschillende collega's van je toch al wel indirect te horen gekregen dat ze "het graag beter zouden zien, als die gasten op de 6e ons nou eens ons gang laten gaan" ).
(ik werk overigens zelf bij een E-dealer, ook ex-E'er trouwens)

[dusty]

Op maandag 10 juni 2002 21:56 schreef blijhoofd_bennie het volgende:
[..]
Ik probeer dus gewoon de gegevens appart te houden van de relatie's. Is hier een benaming voor?
[..]

Ja: "Dom".

Zonder de relaties wordt alle informatie alleen maar gegevens.

[Gerco]

Op dinsdag 11 juni 2002 11:56 schreef Crazy_D het volgende:
Zelfs Eduard zal toch wel weten dat het een zooitje is? (hoewel de meesten het niet rechtstreeks zullen zeggen ("ja het is idd een klerezooitje") heb ik van verschillende collega's van je toch al wel indirect te horen gekregen dat ze "het graag beter zouden zien, als die gasten op de 6e ons nou eens ons gang laten gaan" ).
(ik werk overigens zelf bij een E-dealer, ook ex-E'er trouwens)

We hebben hier geen Eduard en ook geen 6e

Dit is een compleet ander bedrijf, waar toevallig ook Exact Groep op het briefpapier staat. Exact heeft hier ook bijzonder weinig te vertellen, al zijn ze daar niet blij mee.

[whoami]

Nog maar eens:

Op dinsdag 11 juni 2002 11:49 schreef whoami het volgende:

Ja, idd. Misschien kunnen jullie die conversatie verder zetten via mail/irc/watdanook. GoT is niet echt een chatbox...

Dit gaat wel behoorlijk off-topic.

[blijhoofd_bennie]

Op dinsdag 11 juni 2002 09:33 schreef Otis het volgende:
Ik voorspel je een harde klap tegen de muur. Wellicht niet nu maar zeker in de nabije toekomst. Het negeren van bewezen methodieken is al niet echt slim, het met opzet foutief opzetten van een tabellenset is helemaal niet slim. Nu is het een 2 a 3 tabellensetje. Bij een database met meer dan 100 tabellen en een model met meerdere lagen en een veelvoud aan pagina's kom jij er niet meer uit met je 'ik-voel-het-aan-mn-theewater-hier-moet-een-koppeltabel'-methode.

Veel broddelplezier nog.

Bedankt

Maar ff serieus, het echte maken is nog niet begonnen he dus dingen kunnen veranderd worden. Ben nu wel een beetje schermen aan het denken (in ieder geval die fouten uitsluiten)
Maar niets staat nog vast, mijn denkwijze moet je dan ook als onderzoek zien he (dat leek me toch duidelijk)
Ik werk dus wel volgens met methodieken, maar ik wilde ff wat verder zoeken dan die methodieken. En persoonlijk zag ik de voordelen van die "andere" conclussie ook wel.
Maar om dus tot een uiteindelijk goed ontwerp te komen (nadat dus alle informatie 100% bij elkaar is) Komt het uiteindelijke ontwerp te voorschijn.

Dus ik wil vast iedereen bedanken voor de input en jou dus ook

[blijhoofd_bennie]

Op dinsdag 11 juni 2002 11:57 schreef dusty het volgende:

[..]

Ja: "Dom".

Zonder de relaties wordt alle informatie alleen maar gegevens.

Misschien wel, maar als ik er normaal over nadenk (in het echte leven dus) Als je gegevens vind kun je relatie leggen en niet omgekeerd als je bijvoorbeeld alleen relatie's terug zou vinden kom je nooit zo ver als met gegevens (want wat heb je aan relatie's zonder gegevens).
Dus zogezien zou het behoud van gegevens voorop staan. Bij DB's is dit dus anders, denk dus dat ik ff van die denkwijze bij DB's af moet

[blijhoofd_bennie]

Op dinsdag 11 juni 2002 12:44 schreef whoami het volgende:
Nog maar eens:
[..]

Dit gaat wel behoorlijk off-topic.

Hehe ga gerust verder, wordt het alleen wel zo'n "rotzooitje" van

[blijhoofd_bennie]

Op dinsdag 11 juni 2002 09:41 schreef Gerco het volgende:
Ik kan getuigen van de *evil* van de broddelmethode. Hier op mn werk werken we met een 'databaseje' met een tabelletje of 800.

Er is geen enkel model in de organisatie, als iemand iets op moet slaan waar nog geen tabel voor is, maakt 'ie er gewoon 1 aan. Er is geen enkele naming convention, ongeschreven regels of wat dan ook.

Dit resulteert in een GIGANTISCHE teringzooi waarbij NIEMAND weet wat waarvoor dient of waar 'ie wat moet opzoeken. Er zitten ook zeker een 200 ofzo (inmiddels) ongebruikte tabellen in de database, maar omdat er nergens is gedocumenteerd wat welke tabellen waarvoor gebruikt, weet niemand welke dat zijn.

We zijn inmiddels aan een inventarisatie en opruim actie begonnen, maar het einde is voorlopig niet in zicht. Het zal waarchijnlijk minimaal een jaar duren voordat in kaart is gebracht hoe de database er NU uitziet. Dan moeten we nog nadenken over wat we eraan gaan doen...

Vreemd genoeg staat het pakket goed in de markt en verkoopt het als een trein

Afgezien van mijn mogelijke database ontwerp en de fouten die er in zouden kunnen zitten. Ik documenteer wel alles, dus daar ligt bij mij niet het probleem. De voordelen van goede documentatie is me goed duidelijk gemaakt (en geworden) op de stageplek