[Mysql] Relatie tabellen oneindig?

[Gerwin]

Sorry voor de wat vage titel, maar ik weet ook niet precies wat ik nu eigenlijk zoek of welke kant ik op moet gaan. Wat ik wel weet ik wat de relaties moeten zijn. Niet hoe de database er precies uit moet gaan komen te zien. Ik heb al wel verschillende ERD's gemaakt, maar ik kom altijd weer uit op een boomstructuur zoals die hieronder opgebouwd is. Met in de 3e en 4e 'koppel' een loop terug naar 3 en weer naar 4 etc. Ik weet niet goed of dit nu een tekortkoming is van Mysql, mijn kennis of iets anders. Ik zal proberen uit te leggen wat het idee is bij het project, in de hoop duidelijk te krijgen wat het probleem is waar tegenop gelopen wordt.

Laten we aannemen dat ik een hoofdtabel heb met Boeken, deze Boeken hebben Titels, Omschrijvingen, Plaatjes, Filmpjes en een Auteur.

[i]Boeken -> BoekTitel
Boeken -> BoekOmschrijving
Boeken -> BoekPlaatje
Boeken -> BoekFilmpje
Boeken -> BoekAuteur[/i]

Vervolgens heeft een plaatje een eigen Titel, Omschrijvin en Filmpje.

Boeken -> BoekTitel
Boeken -> BoekOmschrijving
[i]Boeken -> BoekPlaatje -> BoekPlaatjeTitel
Boeken -> BoekPlaatje -> BoekPlaatjeOmschrijving
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje[/i]
Boeken -> BoekFilmpje
Boeken -> BoekAuteur

Het filmpje heeft een plaatje, Titel en Omschrijving.

Boeken -> BoekTitel
Boeken -> BoekOmschrijving
Boeken -> BoekPlaatje -> BoekPlaatjeTitel
Boeken -> BoekPlaatje -> BoekPlaatjeOmschrijving
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje
[i]Boeken -> BoekFilmpje -> BoekFilmpjeTitel
Boeken -> BoekFilmpje -> BoekFilmpjeOmschrijving
Boeken -> BoekFilmpje -> BoekFilmpjePlaatje[/i]
Boeken -> BoekAuteur

Tot op dit punt geen probleem 'op zich'. Alles netjes in boomstructeur en niet moeilijk op te zeggen. Echter op het punt met BoekPlaatjeFilmpje en BoekFilmpjePlaatje loopt het wat vaag. Een plaatje voegt eigenlijk een Filmpje toe en een Filmpje een Plaatje. Allebei met eigen titels en weer eigen Plaatjes en Filmpjes.

Als ik bovenstaande verder ga uitschrijven komt er zoiets uit:

Boeken -> BoekTitel
Boeken -> BoekOmschrijving
Boeken -> BoekPlaatje -> BoekPlaatjeTitel
Boeken -> BoekPlaatje -> BoekPlaatjeOmschrijving
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje
[i]Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje -> BoekPlaatjeFilmpjeTitel
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje -> BoekPlaatjeFilmpjeOmschrijving
[b]Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje -> BoekPlaatjeFilmpjePlaatje
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje -> BoekPlaatjeFilmpjePlaatje -> BoekPlaatjeFilmpjePlaatjeTitel
Boeken -> BoekPlaatje -> BoekPlaatjeFilmpje -> BoekPlaatjeFilmpjePlaatje -> BoekPlaatjeFilmpjePlaatjeOms...[/b][/i]
Boeken -> BoekFilmpje -> BoekFilmpjeTitel
Boeken -> BoekFilmpje -> BoekFilmpjeOmschrijving
Boeken -> BoekFilmpje -> BoekFilmpjePlaatje
[i]Boeken -> BoekFilmpje -> BoekFilmpjePlaatje -> BoekFilmpjePlaatjeTitel
Boeken -> BoekFilmpje -> BoekFilmpjePlaatje -> BoekFilmpjePlaatjeOmschrijving
[b]Boeken -> BoekFilmpje -> BoekFilmpjePlaatje -> BoekFimpjePlaatjeFilmpje
Boeken -> BoekFilmpje -> BoekFilmpjePlaatje -> BoekFimpjePlaatjeFilmpje -> BoekFilmpjePlaatjeFilmpjeTitel
Boeken -> BoekFilmpje -> BoekFilmpjePlaatje -> BoekFimpjePlaatjeFilmpje -> BoekFilmpjePlaatjeFilmpjeOms...[/b][/i]
Boeken -> BoekAuteur

etc. etc. Iets zegt me dat ik dat schuingedrukte al achterwege moet laten. Maar dan heb ik natuurlijk niet de Titels van dat nieuwe Plaatje/Filmpje.

Kan iemand me op weg helpen. Bestaat er niet iets dat 'tegelijk' die hele relaties legt zodat ik helemaal niet al die extra 'FilmpjePlaatjeFilmpjePlaatje' etc. tabellen hoeft te maken. Dus zegmaar: "Filmpje en Plaatje zijn gekoppelt totdat er geen nieuwe rows meer ontstaan".

Moet even aangeven dat ik al eens eerder zoiets bij de hand gehad heb, alleen waren er toen veel meer relaties in een soort van 'spin' constructie. Dat project werd wel haalbaar door dingen weg te laten en met subquery's te werken. Echter zie ik hier dat niet zo snel terug, dit omdat ook subquery's weer in een soort van loop moeten werken... ofnie

^help!

[curry684]

Tabel Filmpje en tabel Plaatje. Zoiets als dit dus.

[Gerwin]

curry684 schreef op donderdag 31 juli 2008 @ 20:28:
Tabel Filmpje en tabel Plaatje. Zoiets als dit dus.

We hebben het hier niet meer over bedrijven, filialen, etc. Ik ben juist eerlijk geweest te vermelden dat ik al eens eerder iets gepost heb met waarvan mensen zouden kunnen denken dat ik maar blijf doorgaan met hetzelfde project. Dit nieuwe project is vele malen simpeler en betreft een database voor één site. Dit betreft uiteraard wel een voorbeeld met fictive data die vergelijkbaar is. Het echte en dit voorbeeld heeft wel allebei één 'krul' verwijzing. Hoe is dat te tackelen...? Daar moet toch iets op te vinden zijn zou je zeggen. Hoevaak komt het voor dat een achterliggende "tabel" verwijst naar een vorige en dus zichzelf met die verwijzing ook weer 'outdated' maakt?

[ Voor 6% gewijzigd door Gerwin op 31-07-2008 20:44 ]

[Megamind]

Nou dan nog kan je toch gewoon doen wat Curry zegt?

Je maakt een tabel boeken, een tabel plaatjes en een tabel filmpjes en je joined ze aan elkaar

Boeken| ID | Titel | Auteur

Plaatjes | BoekID | Titel

Filmpjes | BoekID | Titel

Kan je zoveel plaatjes en filmpjes aan een boek hangen... En als je een plaatje aan een filmpje wilt hangen maak je er een extra colom oid bij.

[Verwijderd]

Ik zie geen business case. Ook geen functioneel ontwerp. Ben je al in staat je probleem te beschrijven zonder in technische details te treden? Heb je al vastgesteld wat wel moet kunnen en wat niet?

Ander project of niet, je mist nog steeds de ervaring om met goede oplossingen te komen. Oplossingen zijn altijd oplossingen van een probleem. In dit geval ben je bezig met een technische oplossing voor een technisch probleem dat misschien niet eens nodig is.

Het is niet duidelijk welk probleem op een hoger niveau je wilt tackelen. Waarvoor is deze database? Wie gaan dit gebruiken? Hoe gaat men dit gebruiken?

[Gerwin]

Megamind ik begrijp niet goed wat je bedoeld. Maar misschien zit in je reply wel de oplossing van het probleem wat ik heb. Hieronder een 'classic' ERD diagram van wat ik tot nu heb geprobeerd uit te werken na alle gegevens op papier te hebben verzameld. Alleen weet ik niet hoe dit alles dan in een query moet komen bij 'Boekfilmpje_Plaatje' en 'Boekplaatje_Filmpje' verwijs ik terug naar Boekplaatje en Boekfilmpje, maar die zijn telkens al gekoppeld...



Cheatah, mijn omschrijving geeft hopelijk duidelijk weer wat het probleem is. Exacte 'content' is echt niet nodig. Neem aan dat het een structuur heeft van wat ik geschetst heb met een Boek met Titel, Omschrijving, en een 'weef' voor Plaatjes en Filmpjes met Titels en Omschrijvingen. Dit kan natuurlijk ook het geval zijn met DVD's, klantengegevens, relatiegegevens, etc. maar dat doet voor het probleem niet ter zake lijkt me. Laat staan dat de echte exacte content van de tabellen (namen, telefoonummers etc.) relevant zijn in dit voorbeeld.

Wat ik graag zou willen weten is hoe ik in in mijn voorbeeld uit mijn eerste post en de inmiddels hierboven geposte ERD het voor elkaar kan krijgen dat alles middels één query te 'bundelen' is aan elkaar. Ik blijf maar er maar tegenaanlopen dat tabellen of zaken reeds gekoppeld zijn en later 'gedateerd' zijn. Dan kan ik wel in het oneindig tabellen met een nieuwe alias gaan koppelen, maar waar moet ik dan stoppen, zo ik dit - in mijn ogen niet efficente en goede manier - toch doen?

[ Voor 57% gewijzigd door Gerwin op 31-07-2008 21:23 ]

[curry684]

Ik zie weer tabellen voor omschrijvingen en titels he....

[Gerwin]

curry684 schreef op donderdag 31 juli 2008 @ 21:18:
Ik zie weer tabellen voor omschrijvingen en titels he....

Ach ja ook in dit voorbeeld: 'ja'. Maar we kunnen er ook Telefoonnummers en Groente's van maken ofzo. Die namen zijn fictief en als voorbeeld bedoeld, om het zo duidelijk mogelijk te houden hoe de relaties zijn. Ik had ze ook A, B, C kunnen noemen, het gaat me om de relatie en soort content die die tabbelen bevat. Dat is mij altijd geleerd wat belangrijk is voor het opzetten van een database. Een voorbeeld zoals ik deze hier gepost heb leek me het meest duidelijkst. Toch bedankt voor je opmerking, ik zal de volgende keer een tweede keer nadenken als ik in een voorbeeld de naam van mijn 'tabellen' kies.

[ Voor 21% gewijzigd door Gerwin op 31-07-2008 21:27 ]

[? ?]

Om de zoveel maand kom je hier eens met dezelfde vragen, ofwel over hoe je php output zipt, of over hoe je zware php zaken opdeelt en dan het "Oneindig-veel-joins-tabellen" topic met omschrijvingen, plaatjes en producten en oneindig veel winkels.

Of met nietszeggende tabellen tabelA, tabelB, telkens met enorme grafische voorstellingen, grafen, diagrammen, en noem maar op.

Die namen zijn fictief en als voorbeeld bedoeld, om het zo duidelijk mogelijk te houden hoe de relaties zijn. Ik had ze ook A, B, C kunnen noemen.

niet doen dus... Algemene tabellen die voor alles gelden die bestaan niet. Tabellen dienen om data voor een heel specifieke applicatie in een specifieke situatie op te slaan.
Anders moet je maar een 100 tabellen definieren met alle atomische elementen in, dat lijkt me een goede basis !

Als je het nu nog niet lopend hebt, zou ik het opgeven... Leer normaliseren en begin met 1 winkeltje, kwestie van niet te hoog te mikken. Gewoon wat goede raad. Ik zou ook graag een ruimterobot maken, maar ik begin er niet aan omdat ik weet dat ik dat toch nooit afkrijg...
Zet voor jezelf realistische doelen uit, die je kan bereiken, en dat zal je meer voldoening geven denk ik?

[Mysql] meerdere JOIN's in één, JOIN met WHERE argument

[Mysql] Complexe query (meer-op-meer relatie) 5 tabellen

[Mysql] Random selecties van verschillende tabellen koppelen

[Mysql] "DISTINCT" op gehele row in result

[ Voor 26% gewijzigd door ? ? op 31-07-2008 21:38 ]

[Cartman!]

Sorry dat ik het zeg Gerwin, maar je model slaat echt kant nog wal... hoe je alles aan elkaar denkt te linken, echt..het gaat nergens over. Een boek heeft 1 naam, 1 beschrijving (die info staat dus in de boek tabel) en kan linken aan meerdere plaatjes en/of filmpjes die elk een eigen titel en beschrijving heeft in de eigen tabel (FK naar boek id) en dan ben je er. Ik snap echt niet waarom je zo overdreven moeilijk wil doen...

[.Gertjan.]

Gerwin schreef op donderdag 31 juli 2008 @ 21:26:
[...]

Ach ja ook in dit voorbeeld: 'ja'. Maar we kunnen er ook Telefoonnummers en Groente's van maken ofzo. Die namen zijn fictief en als voorbeeld bedoeld, om het zo duidelijk mogelijk te houden hoe de relaties zijn. Ik had ze ook A, B, C kunnen noemen, het gaat me om de relatie en soort content die die tabbelen bevat. Dat is mij altijd geleerd wat belangrijk is voor het opzetten van een database. Een voorbeeld zoals ik deze hier gepost heb leek me het meest duidelijkst. Toch bedankt voor je opmerking, ik zal de volgende keer een tweede keer nadenken als ik in een voorbeeld de naam van mijn 'tabellen' kies.

Ik denk dat hij bedoelt dat je je database iets te ver hebt genormaliseerd. De kans dat meerdere boeken de zelfde omschrijving hebben of 1 boek meerdere omschrijvingen lijkt me zeer gering. Door zo gigantisch extreem te normaliseren maakt je het heel complex in mijn ogen. Volgens mij kun je het makkelijk doen met de helft van de tabellen..

En ik vind de naming van je tabellen en je colums ook zeer verwarrend. Boek_Omschrijving heeft een primaire key idBoek, en 2 losse foreign keys: Boek_idBoek en idBoekmmschrijving. Sowieso niet echt consistente renaming. Ik weet niet of dat er hier echt toe doet.

[Observer]

Ik zie geen ondersheid tussen entiteiten en attributen van entiteiten: alles is een entiteit en alles heeft zo te zien in de beleving van de TS ook nog eens relatie met elkaar.

Zet alles eens in 1 tabel:

Boeken:
titel, auteur, omschrijving, plaatje, filmpje

Als je wat gegevens invult zul je zien dat bijvoorbeeld auteur iets is wat kan herhalen omdat een auteru meerdere boeken kunnen schrijven. (omschrijvingen zullen zich zeer zelden herhalen en titels ook niet): zet dat in een eigen tabel. Auteurs hebben een naam en je wilt ze kunnen koppelen aan hun boeken, dus krijgen ze een auteur_id en dat veld neem je op in "boeken":

Auteurs:
auteur_id, naam

Boeken:
titel, auteur_id, omschrijving, plaatje, filmpje

Nu heb je misschien meer dan 1 plaatje of filmpje en dat kan op deze manier niet opgelsagen worden. Die kunnen dus ook in hun eigen tabellen en die records kun je weer koppelen middels een ID. Echter, je wilt dus meer dan 1 plaatjea of filmpjes koppelen, en daarvoor zul je een koppel table nodig hebben. Daarvoor moet je boeken ook een id kolom geven:

Plaatjes:
plaatje_id, locatie_van_plaatje

Filmpjes:
filmpje_id, locatie_van_filmpje

Boeken:
boek_id, titel, auteur_id, omschrijving

BoekPlaatjes
boek_id, plaatje_id

BoekFilmpjes
boek_id, filmpje_id

En dat is zo te zien alles wat je nodig hebt. Meer kan ik er niet van maken omdat je niet hebt aangegeven wat je wilt (de business case).

[moto-moi]

Ik kan dit topic wel open laten, maar ik denk dat je het punt wat men gaat maken totaal gaat missen, net zoals je dat in [Mysql] meerdere JOIN's in één, JOIN met WHERE argument ook blijkbaar niet begrepen hebt.
Dat gezegd hebbende:

Het beste wat je kunt doen is een eenvoudig boek over normaliseren bestellen, iets als Database development for dummies (Waarbij jij je niet blind moet staren op de term 'dummies', vaak zijn het hele goede boeken om basisdingen, waar ik normaliseren en het ontwerpen van een database toch echt onder schaar.

Totdat je termen als normaliseren, 3e normaalsvorm etc. begrijpt denk ik eigenlijk in alle eerlijkheid dat je je niet met databases bezig meot houden, je maakt het jezelf echt ongelovelijk moeilijk terwijl wat je wilt helemaal niet zo ingewikkeld is. Succes