Join tussen drie tabellen lukt niet

[anoniem]

[quote:285acb9bec="Annie"]De query wordt: [code:1:285acb9bec] SELECT sponsor.*, sponsor_type.sponsortype_naam FROM sponsor, sponsor_per_sponsor_type, sponsor_type WHERE sponsor.sponsor_id = sponsor_per_sponsor_type.sponsor_id AND sponsor_type.sponsor_type_id = sponsor_per_sponsor_type.sponsor_type_id AND sponsor_type.sponsortype_naam = 'shirt' [/code:1:285acb9bec][/quote:285acb9bec]Rémy is blij met iemand die SQL's eens leesbaar neerzet :lol: [EDIT](alleen zou ik joins ook als echte joins neerzetten, voor de duidelijkheid)[/EDIT] [quote:285acb9bec="Wiep Corbier"]Maar neem van mij aan mijn oplossing de meest gangbare is.[/quote:285acb9bec]En neem van mij aan dat dit niet zo is ;) [quote:285acb9bec="Wiep Corbier"]En ook ik zou in dit geval 3 tabellen hebben, maar dan zo: <KNIP> Tabel 2 ----------------- TypeID (uniek) Sponsor_id (link met Tabel 1) Sponsor_Type <KNIP> [/quote:285acb9bec]Wiep, kijk nu eens heel goed naar tabel 2. Je hebt na al een N:M relatie ;). Alleen TypeID (in tabel 2) is nu redundant geworden, die kan eruit en dan is het exact gelijk aan waarmee wpbremer begon. -Rémy

[anoniem]

PK?' [quote:9dc7ce6c3d]Wiep, kijk nu eens heel goed naar tabel 2. Je hebt na al een N:M relatie[/quote:9dc7ce6c3d] Jij zegt het, maar het is een 1:Meer relatie. Annie, ik heb toch het idee dat je er niet helemaal voor open staat, puur omdat je in een 'stramienetje' zit. Geeft niet :D En je spreekt over shirt en t-shirt. Dan denk ik, je houdt je bezig met de werkelijke waardes en hoe die te veranderen. Vreemd, dat doet helemaal niet terzake. Het gaat om het systeem, het model. Niet de inhoud. En als ik naar je sql kijk, moet ik echt turen om te begrijpen wat er nu eigenlijk gebeurt en erger, waarom in des hemelsnaam. En een discussie over redundantie kun je met BasHamar aangaan. hij twijfelt al :D Als jij een 'link' redundantie noemt houdt het snel op. Ik wil wel eens een 'dataweergave' van jouw tabel 3 zien. Volgens mij heb ik jouw constructie eens in de voorbeelddatabase noordenwind in Access97 gezien. Verder nergens. En ik houd me toch al een jaar of 10 met deze materie bezig, al is dat op hobbybasis.

[anoniem]

[quote:8dab66c21c="Wiep Corbier"]PK?'[/quote:8dab66c21c] PK = Primary Key [quote:8dab66c21c="Wiep Corbier"]Annie, ik heb toch het idee dat je er niet helemaal voor open staat, puur omdat je in een 'stramienetje' zit. Geeft niet :D[/quote:8dab66c21c] Wat jij een stramienetje noemt heet in de database wereld een solide datamodel. Met alle respect voor je 10 jaar hobby ervaring, maar dit is toch wel een van de doodzonden die je kan begaan bij het opzetten van een datamodel. Dat jij het alleen nog maar in de noordenwind database bent tegengekomen is natuurlijk een non-argument. [quote:8dab66c21c="Wiep Corbier"]En je spreekt over shirt en t-shirt. Dan denk ik, je houdt je bezig met de werkelijke waardes en hoe die te veranderen. Vreemd, dat doet helemaal niet terzake. Het gaat om het systeem, het model. Niet de inhoud. [/quote:8dab66c21c]Het probleem is dat in jouw geval het model staat of valt met de inhoud. En daar kan ik me niet in vinden. Een algemene stelregel is dat wanneer data kan wijzigen deze niet niet geschikt is voor een PK. [quote:8dab66c21c="Wiep Corbier"]En een discussie over redundantie kun je met BasHamar aangaan. hij twijfelt al :D Als jij een 'link' redundantie noemt houdt het snel op.[/quote:8dab66c21c] Die discussie is niet nodig, ik heb het namelijk niet over redundantie. Of je PK nu een autonummeringsveld is of een GUID maakt me niet eens zoveel uit zolang deze maar geen 'werkelijke' waarde heeft en imho is dat in jouw oplossing wel het geval.

[anoniem]

Nietes :D Goed, we verschillen van mening. Laten we het daar bij houden.

[anoniem]

[quote:dca60edce2="Annie"][quote:dca60edce2="Wiep Corbier"]PK?'[/quote:dca60edce2]PK = Primary Key[/quote:dca60edce2]Wiep, als je niet weet waar PK (en bijv. FK) voorstaat dan, met alle respect, trek ik je kennis op dit gebied ernstig in twijfel. [quote:dca60edce2="Wiep Corbier"]En je spreekt over shirt en t-shirt. Dan denk ik, je houdt je bezig met de werkelijke waardes en hoe die te veranderen. Vreemd, dat doet helemaal niet terzake. Het gaat om het systeem, het model. Niet de inhoud.[/quote:dca60edce2]Tuurlijk doet de inhoud terzake! De inhoud bepaalt je model! Je ontwikkeld\programmeert een model altijd naar wat er verandert en wat in de toekomst zou kunnen veranderen. Verder sluit ik me aan bij Annie's antwoord. [quote:dca60edce2="Wiep Corbier"]Annie, ik heb toch het idee dat je er niet helemaal voor open staat, ...[/quote:dca60edce2]Wiep, dat heb ik nou juist bij jou ;) [quote:dca60edce2="Wiep Corbier"]En als ik naar je sql kijk, moet ik echt turen om te begrijpen wat er nu eigenlijk gebeurt en erger, waarom in des hemelsnaam.[/quote:dca60edce2]Ik vond dit juist beter te lezen dan elke ander SQL in deze thread, zoals:[code:1:dca60edce2]$SQL_statement = "SELECT * FROM sponsor_type, sponsor_per_sponsor_type, sponsor WHERE sponsor_type.sponsor_type_naam=shirt AND sponsor_type.sponsor_type_id = sponsor_per_sponsor_type.sponsor_type_id AND sponsor_per_sponsor_type.sponsor_type_id=sponsor.sponsor_id"; $resultset= mysql_query($SQL_statement);[/code:1:dca60edce2]. Komt dan ook nog bij dat de namen niet echt lekker gekozen zijn, IMHO, waardoor elke SQL-string slecht leesbaar wordt. Ook zou ik joins niet in de WHERE-clause zetten voor de duidelijkheid. Ik zou zoiets doen:[code:1:dca60edce2]SELECT sponsor.*, type.sponsortype_naam FROM sponsor INNER JOIN sponsor_per_sponsor_type AS link ON sponsor.sponsor_id = link.sponsor_id INNER JOIN sponsor_type AS type ON type.sponsor_type_id = link.sponsor_type_id WHERE type.sponsortype_naam = 'shirt'[/code:1:dca60edce2]In MySQL kun je dan nog zelfs verder gaan door USING te gebruiken, zoals onderstaand. Dan is het in een oogoplag duidelijk(althans voor een DBA'er):[code:1:dca60edce2]SELECT sponsor.*, type.sponsortype_naam FROM sponsor INNER JOIN sponsor_per_sponsor_type USING (sponsor_id) INNER JOIN sponsor_type AS type USING(sponsor_type_id) WHERE type.sponsortype_naam = 'shirt'[/code:1:dca60edce2][quote:dca60edce2="Wiep Corbier"]Volgens mij heb ik jouw constructie eens in de voorbeelddatabase noordenwind in Access97 gezien. Verder nergens. En ik houd me toch al een jaar of 10 met deze materie bezig, al is dat op hobbybasis.[/quote:dca60edce2]Die constructie is hoe je een N:M-relatie ('Many to Many'-relatie) realiseert. Dat jij deze nergens ander hebt gezien komt volgens mij omdat je deze niet herkent, gezien je volgende antwoord:[quote:dca60edce2="Wiep Corbier"]Jij zegt het, maar het is een 1:Meer relatie.[/quote:dca60edce2]Nogmaals kijk eens heel goed... Je hebt een N:M-relatie gecreëerd! Als ik jouw tabellen als een diagram schrijf dan ziet dat er zo uit:[code:1:dca60edce2] 1 n n 1 sponser(tabel1) ----- koppeltabel(tabel2)-----sponsertype(tabel3)[/code:1:dca60edce2]De tabel 2 fungeert puur als koppeltabel, om tabel 1 en 2 te koppelen. Deze constructie bestaat uit twee 1:n-relaties ('One-to-Many'-relaties) die tezamen de N:M-relatie vormen. Dat je hierbij sponser_type als PK heb gedefineerd ipv een nieuwe Sponser_type_id is een andere discussie. In deze andere discussie ben ik het met Annie eens ben, maar aan de andere kant, als de relatie gedefinieerd is met CASCADE UPDATE zou het geen probleem hoeven zijn (maar mijn voorkeur heeft het in ieder geval niet). Ook is in deze tabel 2 (de koppeltabel), zoals ik al eerder gepost heb, de TypeID zinloos. Wat wel handig is een compound key (key die uit meedere kolommen bestaat) zodat het uniek en geïndexeerd is. -Rémy

[anoniem]

Maar je had een probleem en dat is nu opgelost. Daar is dit forum voor. Ik wil het dan ook hier bij laten.

[anoniem]

[quote:9dfd43bfd9="Remytje"]...maar aan de andere kant, als de relatie gedefinieerd is met CASCADE UPDATE zou het geen probleem hoeven zijn (maar mijn voorkeur heeft het in ieder geval niet). [/quote:9dfd43bfd9]Mijn stem krijgt die oplossing ook niet aangezien je daarmee weer impliceert dat het geen probleem is dat de PK wijzigt. Het wordt zo misschien wel een principe kwestie, maar een CASCADE UPDATE is eigenlijk -als je strikt naar de letter leeft- een ranzige techniek. btw. Wiep, het is natuurlijk nergens mijn bedoeling geweest om je persoonlijk aan te vallen (je trekt je ineens zo snel terug uit de discussie). Ik hoop alleen dat je toch nog eens serieus kijkt naar wat er hierboven gezegd is en heel misschien kan ik je dan alsnog overtuigen, je bent natuurlijk nooit te oud om te leren. ;)

[anoniem]

Beste Annie, uit diverse bijdrages van mij over jou blijkt dat ik een enorm respect heb voor je kennis. Maar uit jouw antwoord en die van Remytje blijkt dat jullie beide absoluut niet zien wat ik bedoel. Ik gebruik een zeer gebruikelijke techniek, waarvan lijkt of het arabisch voor jullie is. Mijn voorbeelden worden compleet verkeerd geïnterpreteerd, en dan weet ik niet meer hoe ik het dan nog moet uitleggen. Ik stel bijvoorbeeld dat ik een 1:M relatie gebruik wat door jullie beide wordt ontkent. Ik zeg dat ik twee tabellen gebruik, 1 hoofdtabel met daaraan een subtabel. De waardes van tabel 3 waar bijvoorbeeld shirt en bal in staan is een opzoektabel die net zo goed een array kan zijn. Daar begrijpen jullie geloof ik helemaal niets van. Gaat ie nog eenmaal: EN a.u.b. even aandachtig lezen. Mijn model komt voort uit de theorie van normalisatie. Dat houdt in (wellicht ten overvloede) dat je die gegevens bij elkaar in een tabel stopt die direct met elkaar te maken hebben, EN dat je er voor zorgt dat gegevens niet redundant vookomen - in andere tabellen dus. MAAR een link mag je gewoonweg niet redundantie noemen. Zo ontstaat tabel 1 met gegevens over de sponsor. Zoals adresgegevens. MAAR: feitelijk is dit Tabel 1 (Sponsor) SponsorID (PK Uniek, autonummering) SponsorNaam; SponsorAdres; etc. ----------------------------------------------- Dan tabel 2. (Type) Tabel 2 krijgt TypeID (PK, Uniek, autonummering) SponsorID (Link met Tabel 1) TypeNaam (inhoud...'Shirt', 'Bal', etc) Doordat Tabel 2 gelinkt is met tabel 1 d.m.v. SponsorID heb ik de mogelijkheid gecreeërd om talloze soorten sponsering aan een sponsor te hangen. Twee tabellen dus. In het kort de SQL: Select Tabel1, Tabel2 where TypeNaam = 'Shirt' Dan krijg je alle sponsoren die shirtsponsor zijn. Waar komt mij 'derde' tabel dan vandaan die Remytje onterecht als koppeltabel ziet in zijn analyse over mijn zeer eenvoudige systeem? Net als eerder vermeld zou ik Shirt, Bal etc vanuit een RunTime Array in mijn tabel kunnen plaatsen maar ik kan dat ook vanuit een derde tabel genaamd TypeNaam kunnen doen. Nu doe ik dat en dan is het [b:8002007570]niet[/b:8002007570] een koppeltabel, want deze derde tabel, is ALLEEN aan tabel 2 gekoppeld. Dus: Tabel1 -> Tabel2 -> (eventueel)Tabel 3. [img:8002007570]http://212.120.108.145/Images/Sponsor.jpg[/img:8002007570] LET OP: uit dit plaatje blijkt toch duidelijk de 1:Meer relatie? De derde tabel levert waardes als 'shirt' 'Bal' etc aan Tabel 2. Hoeft niet, je kunt ze telkens met de hand invoeren (niet slim i.v.m. typefouten), uit een ArrayList op je website danwel Winformulier halen, of zoals ik dus nu doe uit een tabel. Wederom, Tabel 3 heeft wel een PK, en dat is tevens een unieke waarde en ook in dit geval niet een autonummering, want daar heb ik niets aan. Nb: Annie, jij stelt dat een PK niet veranderbaar [i:8002007570]hoort[/i:8002007570] te zijn, maar dan vraag ik je: why the hell not? ( in het geval van tabel 3 dan uiteraard) ps: Tussen adresgegevens staat o.a. de gemeente. Heb ik weinig sponsoren en voornamelijk uit de directe omgeving en is dat al jaren zo, dan zou ik dat af kunnen doen met een RunTime ArrayList. Zijn er vele sponsoren uit allerlei gemeentes en wisselen die ook nog een regelmatig dan kies ik voor een tabel. Gewoonte is dan om een tabel met een GemeenteID (PK Uniek) en Gemeentenaam aan te maken. Ik kies voor ALLEEN gemeentenaam, omdat GemeenteID niets toevoegt aan de functionaliteit. Sterker, het maakt het voor beginnende ontwikkelaars iets moeilijker. Ik hoop dat het nu echt duidelijk is geworden, duidelijker kan ik het niet uitleggen.

[anoniem]

Wiep, je verhaal is duidelijk. Je maakt een keuze tussen gebruik van alleen de Sponsor en de Type table (ik noem dat even optie 1) of je voegt een derde table TypeNaam toe (optie 2). Hieronder mijn visie hierop. Bij optie 1 heb je twee tables waar tussen een 1-N relatie bestaat. Echter daarbij voldoe je niet aan de gangbare normalisatie regels omdat je daarbij wel degelijk redundantie hebt van gegevens. Dat jij een "opzoek-array" gebruikt in je applicatie verandert daar niets aan. Het zijn twee verschillende lagen (tiers) in je applicatie en de normalisatie regels zijn niet van toepassing op je logic- cq. presentatie-tier. Als je de derde table toevoegt (in optie 2) dan heb je een 1-N relatie tussen Sponsor en Type, en heb je een 1-M relatie tussen TypeNaam en Type. De table Type is in dit geval dus de koppeltabel tussen deze twee entiteiten die een N-M relatie hebben. Echter is kan ik me in deze optie niet vinden in de gekozen PK. Deze is er namelijk niet alleen om de row te identificeren, maar heeft ook een betekenis in de real world. Met andere woorden zou dat een kandidaat kunnen zijn voor wijzigingen. En ik ben wat dat betreft best principieel ingesteld, een PK is er om bepaalde gegevens uniek te identificeren. Als deze kan wijzigen dan is het toch geen uniek identificerende key meer? Op dat moment zal je ook meteen alle references naar deze key moeten wijzigen met alle mogelijke gevaren van dien (data consistentie). Nu is dat laatste wel weer op te lossen met de eerder genoemde cascaded updates, maar dat is feitelijk een oplossing aandragen voor iets wat nooit een probleem had hoeven worden (namelijk door een andere PK te kiezen). Ik geef je overigens volledig gelijk als je dit op sommige vlakken principieel-theoretisch-gemier-in-de-diepte vindt ;) Het is alleen wel iets wat je imho als developer moet weten. Dat iemand op basis daarvan een keuze maakt waar ik me niet in kan vinden moet men zelf weten natuurlijk. It's just my 2 cents.

[anoniem]

[quote:38fd80b0f4]Als deze kan wijzigen dan is het toch geen uniek identificerende key meer? [/quote:38fd80b0f4] Probeer maar eens tweemaal het woord 'shirt' in te voeren Wat heeft het feit dat je iets kunt veranderen te maken met het feit of iets uniek is of niet? Stel nu eens dat ik in TypeNaam het woord 'shirt' heb staan en ik verander dat in 'spelersshirt. Ook al heb ik een miljard records, dan maakt niets uit. Ik hoef niets speciaals te doen. Ik zou zeggen: neem het model eens over, vul het met een aantal gegevens en probeer het eens uit. Welkom in 2004 :lol:

[anoniem]

[quote:5d7d059c84="Wiep Corbier"]Wat heeft het feit dat je iets kunt veranderen te maken met het feit of iets uniek is of niet?[/quote:5d7d059c84] Ik heb het niet over "uniek" (als in unique constraint), ik heb het over "uniek identificerend" (als in primary key). Als ik het veld wijzig dan begint mijn database te klagen dat er nog references naar deze key liggen. [quote:5d7d059c84="Wiep Corbier"] Stel nu eens dat ik in TypeNaam het woord 'shirt' heb staan en ik verander dat in 'spelersshirt. Ook al heb ik een miljard records, dan maakt niets uit. Ik hoef niets speciaals te doen.[/quote:5d7d059c84] Mja, maar dat komt waarschijnlijk omdat je access gebruikt (toch?). Nu ken ik dat pakket niet van binnen en buiten, maar ik kan me zo voorstellen dat deze op dat moment dus automatisch een cascaded update voor je doet. Of misschien zelfs intern al werkt met een eigen guid om de tables te koppelen.

[anoniem]

[quote:4d47870da6="Annie"]maar ik kan me zo voorstellen dat deze op dat moment dus automatisch een cascaded update voor je doet. Of misschien zelfs intern al werkt met een eigen guid om de tables te koppelen.[/quote:4d47870da6]Access en slimme features?? Heb je gedronken of zo? ;) Verder ben ik het volkomen met Annie eens, het is _echt_ gebruikelijk om een aparte PK te maken voor die TypeNaam...

[anoniem]

Het is ook gebruikelijk om een PK te gebruiken in een tabel als TypeNaam. Alleen, IK doe dat niet omdat het niets toevoegt....VIND IK. En met PK bedoel ik [b:d5ecf4f85f]in dit geval een[/b:d5ecf4f85f] PK van het type autonummering. Want voor de goede orde, TypeNaam is uiteraard een PK, maar ik neem maar even aan dat Bill hier een PK van het type autonummering bedoelt. Autonummering gebruik IK vrijwel [b:d5ecf4f85f]alleen in een subtabel[/b:d5ecf4f85f], omdat een autonummeringveld niet een waarde heeft die ik ooit nodig zal hebben in een sql-string. En Annie, je snapt mij niet. Je ziet mij dingen 'doen' die niet bestaan er geeft er nog een naam aan ook. Gooi die grijze massa van je eens helemaal leeg, en lees nogmaals mijn uitleg door. Zie het licht!

[anoniem]

[quote:4d7be694fc]Bij optie 1 heb je twee tables waar tussen een 1-N relatie bestaat. Echter daarbij voldoe je niet aan de gangbare normalisatie regels omdat je daarbij wel degelijk redundantie hebt van gegevens.[/quote:4d7be694fc] Niet gangbaar? Noordenwind 2003 [img:4d7be694fc]http://212.120.108.145/Images/Noordenwind.gif[/img:4d7be694fc] Ik ben ook in het bezit van SQL-server2000 en daar wordt het 'oude' systeem weergegeven door Annie nog toegepast. Maar tijd houdt geen pauze. Blijf evolueren mensen!! En vooral: denk ZELF.

[anoniem]

Wiep, even helemaal los van de discussie: met welk programma maak je bovenstaande overzichten? Ziet er bijzonder handig en overzichtelijk uit! - Bas

[anoniem]

Access. En dergelijke overzichten heb je ook in SqlServer2000

[anoniem]

[quote:d7a915bee8="Wiep Corbier"]Niet gangbaar? Noordenwind 2003 [..] Blijf evolueren mensen!! En vooral: denk ZELF.[/quote:d7a915bee8]Ik vind het toch *hoogst* opmerkelijk dat je op de Northwind database wijst alsof die perfect is en vervolgens loopt te verkondigen dat je vooral zelf moet denken :-? Nog een aardig stuk software voor dit soort diagrammen: [url=http://www.datanamic.com/]DeZign for Databases[/url]. Daarmee maak je database onafhankelijke diagrammen die je kan exporteren naar verschillende database formaten.

[anoniem]

[quote:cee056d02e]Ik vind het toch *hoogst* opmerkelijk dat je op de Northwind database wijst alsof die perfect is[/quote:cee056d02e] Waar zeg ik dat? Annie beweert dat mijn manier niet gangbaar is. Ik bewijs het tegendeel.

[anoniem]

[quote:5a2d93bced="Wiep Corbier"]Annie beweert dat mijn manier niet gangbaar is. Ik bewijs het tegendeel.[/quote:5a2d93bced]Ik vind één voorbeeld echt geen bewijs, Annie kan vast ook wel één voorbeeld vinden zodat hij gelijk heeft. Is dat een bewijs dan? Maar goed, we zullen het wel oneens blijven met elkaar ;)

[anoniem]

[quote:721780c4f5="Wiep Corbier"]Maar uit jouw antwoord en die van Remytje blijkt dat jullie beide absoluut niet zien wat ik bedoel.Ik gebruik een zeer gebruikelijke techniek, waarvan lijkt of het arabisch voor jullie is. Mijn voorbeelden worden compleet verkeerd geïnterpreteerd, en dan weet ik niet meer hoe ik het dan nog moet uitleggen.... ...En Annie, je snapt mij niet. Je ziet mij dingen 'doen' die niet bestaan er geeft er nog een naam aan ook. Gooi die grijze massa van je eens helemaal leeg, en lees nogmaals mijn uitleg door. Zie het licht![/quote:721780c4f5]Annie (als ik even voor je mag spreken, zo niet: let me know ;)) en ik zien absoluut wat jij bedoelt. Het is geen arabisch voor ons, je voorbeelden zijn duidelijk, wij zien jouw geen dingen 'doen' die niet bestaan. Wat je doet is een zeer gebruikelijke techniek. Probleem is alleen dat zowel Annie als ik proberen aan te geven dat je deze techniek verkeerd uitvoert (je voert de normalisatie-regels niet ver genoeg door) en zie jij helaas niet het licht. Nou klinkt dit misschien arrogant, maar neem dit nou gewoon aan van een professioneel DBA'er (spreek nu alleen voor mijzelf, aangezien ik niet weet wat Annie als beroep doet). Ik zal proberen dit duidelijk te maken, door van jouw voorbeeld\model (\jouw manier) onderuit te halen (doe dit allemaal in Access, zodat er geen discussie kan onstaan, als ik het in SQLserver of in UML zou doen). Ik doe deze moeite om jou te laten zien hoe het wel moet, zodat je daarmee beter wordt. Als jij dan nog vindt dat ik ongelijk heb, dan geef ik het op en leg ik mij er bij neer dat we het niet eens zullen worden ;). [quote:721780c4f5="Wiep Corbier"]Ik stel bijvoorbeeld dat ik een 1:M relatie gebruik wat door jullie beide wordt ontkent. [/quote:721780c4f5]Nee, dit wordt niet door ons ontkent. Wij zeggen alleen dat je TWEE 1:n-relaties hebt! Deze twee vormen samen (in deze situatie) een n:m-relatie ('Many-to-Many'-relatie). Vervolgens noem je deze n:m-relatie, voor zover ik het begrijp, een ouderwets systeem, dat wij dienen te evolueren\zelf na te denken. Hier reageer ik geeneens op, want dit geeft mij het gevoel van :roll: (en dat zal voor Annie, denk ik, hetzelfde zijn). [quote:721780c4f5="Wiep Corbier"]feitelijk is dit Tabel 1 (Sponsor) SponsorID (PK Uniek, autonummering) SponsorNaam; SponsorAdres; etc. ----------------------------------------------- Dan tabel 2. (Type) Tabel 2 krijgt TypeID (PK, Uniek, autonummering) SponsorID (Link met Tabel 1) TypeNaam (inhoud...'Shirt', 'Bal', etc) Doordat Tabel 2 gelinkt is met tabel 1 d.m.v. SponsorID heb ik de mogelijkheid gecreeërd om talloze soorten sponsering aan een sponsor te hangen. [/quote:721780c4f5]Je hebt nu inderdaad deze mogelijkheid gecreëerd met twee tabellen. Het model ziet er als volgt uit: [img:721780c4f5]http://www.ourselves.nl/example2/relation_step1.png[/img:721780c4f5] Dit model heeft een aantal problemen: [b:721780c4f5]Probleem 1.[/b:721780c4f5] Ik kan voor TypeNaam alles invullen wat ik wil (maakt niet uit hoe onzinnig het is) en ik kan typefouten maken (shirt <> sihrt) en de DB accepteert dit gewoon; [b:721780c4f5]Probleem 2.[/b:721780c4f5] TypeNaam bevat redunante gegevens. Dit betekend dat TypeNaam op meedere plekken gedefineerd is. Dit test ik door de vraag te stellen: Als ik TypeNaam aanpas, kan ik dit op ÉÉN plaats doen? Nee, want ik moet bij een aanpassing van shirt -> t-shirt, dit in alle rijen gaan aanpassen (door [i:721780c4f5]UPDATE Type SET TypeNaam='t-shirt' WHERE TypeNaam='shirt';[/i:721780c4f5]). Jij probeert deze problemen als volgt op te lossen: [quote:721780c4f5="Wiep Corbier"]Waar komt mij 'derde' tabel dan vandaan die Remytje onterecht als koppeltabel ziet in zijn analyse over mijn zeer eenvoudige systeem? Net als eerder vermeld zou ik Shirt, Bal etc vanuit een RunTime Array in mijn tabel kunnen plaatsen maar ik kan dat ook vanuit een derde tabel genaamd TypeNaam kunnen doen.[/quote:721780c4f5] Met deze derde tabel (die ik niet als koppeltabel zie, maar tabel 2 'Type'!!!), ziet jouw model als volgt eruit: [img:721780c4f5]http://www.ourselves.nl/example2/relation_step2.png[/img:721780c4f5] (Annie, die dunne lijn is een FK met ON DELETE\UPDATE NO ACTION, dus is niet een echte FK constrain (biedt niets meer dan een Array)). Zowel bij een Array als deze tabel3, lossen nog steeds probleem 1 niet op: je kan nog steeds onzin invullen\typefouten maken. Jij vindt dit van niet omdat jij dit in een web- cq acces-formulier beperkt, maar dient de DB\model zelf te beperken! Probleem 2 bestaat ook nog steeds. Als ik namelijk de TypeNaam aanpas (shirt -> t-shirt) in de tabel3 of in de Array, dan dien ik nog steeds elke record in de tabel Type aan te passen, in tegenstelling tot wat jij beweert: [quote:721780c4f5="Wiep Corbier"]Stel nu eens dat ik in TypeNaam het woord 'shirt' heb staan en ik verander dat in 'spelersshirt. Ook al heb ik een miljard records, dan maakt niets uit. Ik hoef niets speciaals te doen.[/quote:721780c4f5]Wiep, probeer maar eens in tabel3 TypeNaam aan te passen. In tabel2 Type wordt het veld TypeNaam NIET automatisch aangepast! Hopelijk erken je dat bovenstaande problemen nog niet zijn opgelost, door mijn uitleg erbij. Zo niet, dan heeft onderstaande tekst ook niet veel zin. Om probleem 1 écht goed op te lossen (de DB\model beperkt zelf de invoer), dan valt een array zoiezo af. Tabel3 is wel goed alleen passen wij de relatie (wat jij dan link noemt) aan, door 'Enforce Referential Integrity' aan te vinken (ON DELETE\UPDATE NO ACTION van de FK vervalt dan). [img:721780c4f5]http://www.ourselves.nl/example2/relation_step3.png[/img:721780c4f5] Je krijgt dan het volgende model: [img:721780c4f5]http://www.ourselves.nl/example2/relation_step4.png[/img:721780c4f5] In dit model is het alleen nog maar mogelijk uit tabel3 TypeNaam te kiezen. Andere opties zijn niet mogelijk (de DB weigert dit). Probleem 1 OPGELOST! We hebben nu TWEE 1:n-relaties die samen een n:m-relatie ('Many-to-Many'-relatie) vormen!!!! Zitten we nu alleen nog met probleem 2. Als wij nu shirt in t-shirt willen veranderen dan zal de DB dit weigeren, aangezien er gerelateerde records in tabel2 Type bevinden. Dit betekend dat onze PK niet goed gekozen is. De oplossing is door hier een nieuw veld met een autonummering ID aan te maken. Een andere, maar slechter oplossing, is door de relatie (FK) aan te passen met UPDATE CASCADE. UPDATE CASCADE zorgt ervoor dat als je shirt naar t-shirt veranderd, dat in tabel2 ook alle waardes met shirt in t-shirt veranderen. Als we nu nog eens goed kijken naar het model, dan komt er nog een probleem te voorschijn. Ik kan een dezelfde sponser meedere keren aan het zelfde type koppelen, zonder dat de DB\model dit weigert. Onderstaand is gewoon mogelijk:[code:1:721780c4f5] TypeID SponserId TypeNaam --------- ------------ ------------ 1 4 shirt 2 7 voetbal 3 4 shirt 4 4 broek 5 8 shirt[/code:1:721780c4f5] Dit is op te lossen door te zorgen dat SponserId en TypeNaam, samen, uniek zijn. Eigelijk is dit de PK. Dan rijst meteen ook de vraag op: Wat is TypeID? Aan de naamgeving zou je denken dat het een ID is per type, maar dit is niet zo (ID 1, 3 en 5 verwijzen alle drie naar shirt). TypeID is gewoon nutteloos\redunant in deze tabel2! Het zou veel logischer zijn om deze in tabel3 te zetten (en UPDATE CASCADE uit te schakelen). Ook heeft tabel3 TypeNaam een rare naam: het stelt geen enttiteit\object voor. Als je kijk naar de inhoud zijn het types, dus de deze tabel zou Type moeten heten en niet table2! Dit is volgens mij ook het kern van het probleem bij jou: Je ziet tabbelen niet als entiteiten\objecten met relaties. Hierdoor maak je ontwerpfouten in je model. Het model (zoals ik het zou doen) zou dan als volgt worden: [img:721780c4f5]http://www.ourselves.nl/example2/relation_step5.png[/img:721780c4f5] [quote:721780c4f5="Wiep Corbier"]Het is ook gebruikelijk om een PK te gebruiken in een tabel als TypeNaam. Alleen, IK doe dat niet omdat het niets toevoegt....VIND IK. [/quote:721780c4f5]Laat ik dan eens heel flauw zijn en deze regel doortrekken. Waarom heb je dan wel een SponserId? Deze voegt dan ook niets toe.... [quote:721780c4f5="Wiep Corbier"]En met PK bedoel ik [b:721780c4f5]in dit geval een[/b:721780c4f5] PK van het type autonummering. Want voor de goede orde, TypeNaam is uiteraard een PK, maar ik neem maar even aan dat Bill hier een PK van het type autonummering bedoelt. [/quote:721780c4f5]Een PK van het type autonummering bestaat niet. Een PK is een constraint die eist dat de kolom(en), waarop de PK constraint op wordt toegepast, uniek is en niet NULL is. Dat de kolom uniek is doordat hier een autonummering op is toegepast heeft niets met PK te maken. [quote:721780c4f5="Wiep Corbier"]Niet gangbaar? Noordenwind 2003[/quote:721780c4f5]Dus jij beweert met een Noordenwind2003-voorbeeld het tegendeel te bewijzen? Ik zie even niet hoe je met dit voorbeeld, het tegendeel kan berweren? Het Noordenwind2003-voorbeeld is juist een voorbeeld die Annie en ik kunnen gebruiken (het bevat zelfs een n:m-relatie :roll:). jouw model zie ik hier in de verste verte niet in terug. -Rémy