[CMS] meer op meer relaties tussen content

[Verwijderd]

Ik ben bezig een opzet te maken voor een database voor een CMS, de, er versimpelde basis is:

content tabel
content_soort tabel

in de content tabel staat de inhoud van de site
in de content_soort staan de verschillende soorten content.

voorbeeld: Als content_soort heb ik "aflevering", "acteur" en "foto".

Probleem: Nu wil ik een meer op meer relatie kunnen hebben tussen alle content.
In het voorbeeld: Een aflevering heeft een meer op meer relatie met een acteur, maar een acteur kan ook een meer op meer relatie hebben met een foto.

Iemand een idee hoe dit het beste aangepakt kan worden?

[gorgi_19]

Een koppelingstabel maken?

ID int
ContentID int
ContentSoortID int

[Verwijderd]

maar dan maak je een relatie tussen de content en de contentsoort.
Wat ik wil bereiken is meer op meer relaties tussen content onderling

[Verwijderd]

id
aflevering
acteur

id
acteur
foto


hoppa 2 tabelletjes voor de realties erbij...

[Verwijderd]

dat is inderdaad een optie, voor elke meer op meer relatie een koppeltabel maken, maar de 3 soorten content zijn slechts ter voorbeeld, dat kunnen er ook 10 zijn,
en dan zou ik 10 koppeltabellen moeten aanmaken...
zou het niet anders (beter) kunnen?

[-Klimaks-]

Wat dacht je van:
ID
ContentSoort_1_ID
Content_1
ContentSoort_2_ID
Content_2

[Verwijderd]

aanvulling:
maar aangezien acteur, aflevering en foto in de zelfde tabel content staan zou je deze tabellen dan ook samen kunnen voegen.
Dan kom je eigenlijk op 't idee wat ik oorspronkelijk had:

één koppeltabel voor alle reaties. met daarin:

id
contentid_1
contentid_2


maar op de een of andere manier komt deze manier nogal "vreemd" over.

<edit>zo'n beetje als -Klimaks- voorstelt dus</edit>

[Verwijderd]

Op donderdag 27 juni 2002 23:31 schreef zjos het volgende:
aanvulling:
maar aangezien acteur, aflevering en foto in de zelfde tabel content staan zou je deze tabellen dan ook samen kunnen voegen.
Dan kom je eigenlijk op 't idee wat ik oorspronkelijk had:

één koppeltabel voor alle reaties. met daarin:

id
contentid_1
contentid_2


maar op de een of andere manier komt deze manier nogal "vreemd" over.

nee toch? dit is gewoon goed hoor, en nog de beste oplossing ook volgens mij... (zo zou ik het zelf gedaan hebben iig)

edit:

Niet zoals klikmaks het heeft, je moet gewoon met 3 velden afkunnen (alle 3 integer), namelijk een auto_increment id, en 2 id's uit je andere tabel waartussen je een relatie wil leggen

[TheDane]

_{just in case:}
bij bovenstaande oplossing moet je dus wel zorgen dat alle content_items (ook van verschillende types) van 1 gezamelijke auto_increment ID gebruik maken, anders weet je in je koppeltabel niet naar welk itemtype (table) je verwijst

[Verwijderd]

daarom ook "zo'n beetje"
goed. maar hier op doorgaand,
stel dat in de koppeltabel 't volgende staat:

id | contentid_1 | contentid_2
1 | 1 | 2
2 | 1 | 3
3 | 4 | 1

en ik wil via SQL alle relaties die aan contentid "1" zitten, dan krijg ik toch alleen terug: contentid 2 en 3 niet?
Dus om 4 ook terug te krijgen moet ik dan ook in de koppeltabel toevoegen

id | contentid_1 | contentid_2
4 | 1 | 4

toch?
Is het nog een beetje te volgen

[Verwijderd]

Op donderdag 27 juni 2002 23:43 schreef TheDane het volgende:

bij bovenstaande oplossing moet je dus wel zorgen dat alle content_items (ook van verschillende types) van 1 gezamelijke auto_increment ID gebruik maken, anders weet je in je koppeltabel niet naar welk itemtype (table) je verwijst

klopt, maar dat is bij de huidige opzet ook zo. Alle content staat in één tabel, met één gezamelijke sleutel

[VisionMaster]

Wil je een meer-op-meer relatie maken in een SQL based database, dan hebbie echt een tussen-tabel nodig.

Dit is basic database-ontwerpen.

Mogelijk wil je een andere oplossing of vatje um niet ... allemaal possible ... Maar dan moet je iets meer duidelijk maken van wat je doel is. Ik vind het nogal vaag.

[Verwijderd]

Op donderdag 27 juni 2002 23:57 schreef VisionMaster het volgende:
Wil je een meer-op-meer relatie maken in een SQL based database, dan hebbie echt een tussen-tabel nodig.
Dit is basic database-ontwerpen.

daar heb je helemaal gelijk in.
Waar ik mee zit is:
- ik had nog nooit met een koppeltabel gewerkt waar in de IDs waarnaar verwezen wordt uit één tabel komen, en weet dus ook niet of dit kan/mag/goedgaat
- het probleem van gegevens opvragen in deze koppeltabel, waar verwijzingen instaan naar maar één tabel (zie bovenstaande post)

[Dentist]

Op donderdag 27 juni 2002 23:47 schreef zjos het volgende:
daarom ook "zo'n beetje"
goed. maar hier op doorgaand,
stel dat in de koppeltabel 't volgende staat:

id | contentid_1 | contentid_2
1 | 1 | 2
2 | 1 | 3
3 | 4 | 1

en ik wil via SQL alle relaties die aan contentid "1" zitten, dan krijg ik toch alleen terug: contentid 2 en 3 niet?

Dan is je query gewoon brak.

SELECT * from tabel where contentid_1 = '1' or contentid_2 = '1';

Dentist

[Verwijderd]

Op vrijdag 28 juni 2002 00:32 schreef Dentist het volgende:

SELECT * from tabel where contentid_1 = '1' or contentid_2 = '1';

maar wat komt er dan bv uit:

id | contentid_1 | contentid_2
1 | 1 | 2
2 | 1 | 3
3 | 4 | 1


maar de lijst die je moet hebben is:
2
3
4

Het probleem is dat de bijbehordende ID's verdeeld zijn over twee kolommen, dit wil ik dus ondervangen door de koppelingen 2 maal op te nemen,
dus
4 | 1
1 | 4

[Dentist]

Je kan natuurlijk ook de query 2x laten lopen, eerst door id1 en dan door id2. Ondertussen vul je gewoon een array met die waarden.

Lijkt me makkelijker dan een tabel 2x zo groot maken..

Dentist

[-Klimaks-]

Op vrijdag 28 juni 2002 01:29 schreef Dentist het volgende:
Je kan natuurlijk ook de query 2x laten lopen, eerst door id1 en dan door id2.

Ik zie eigenlijk niet in wat er mis is met die eerste query van je, maar dat ligt waarschijnlijk aan het belachelijk vroege uur

Maar ipv dan de query 2 maal te laten lopen, kan je dus beter een union gebruiken imho

SELECT * from tabel contentid_1 = 1
union
select * from tabel where contentid_2 = 1;

[Dentist]

Op vrijdag 28 juni 2002 05:54 schreef -Klimaks- het volgende:

[..]

Ik zie eigenlijk niet in wat er mis is met die eerste query van je, maar dat ligt waarschijnlijk aan het belachelijk vroege uur

Maar ipv dan de query 2 maal te laten lopen, kan je dus beter een union gebruiken imho

SELECT * from tabel contentid_1 = 1
union
select * from tabel where contentid_2 = 1;

Hehehhe, hij wil 1 kolom met gegevens, dus niet alle records met id, contentid_1 en contentid_2 (wat volgens mij ook met die union gebeurt), maar aan de tijd te zien moet je hoognodig gaan slapen, of ander werk zoeken

[Verwijderd]

Oplossing:
Op de volgende manier krijg je een rij terug met alle bijbehorende content, zonder dat je de rijen dubbel op moet nemen

SELECT CONTENT_ID2 AS [RESULT]
FROM RELATIES
WHERE content_id1 = 1
UNION SELECT CONTENT_ID1 AS [RESULT]
FROM RELATIES
WHERE content_id2 = 1;

[drm]

ID int
ContentID int
ContentSoortID int

id
contentid_1
contentid_2

ID
ContentSoort_1_ID
Content_1
ContentSoort_2_ID
Content_2

etcetera

Het heeft geen enkele zin een auto_increment ID in een koppeltabel te stoppen. In een koppeltabel vullen de sleutels samen een compound primary key, en daarmee zijn alle combinaties verplicht uniek.

[Verwijderd]

Op vrijdag 28 juni 2002 12:33 schreef drm het volgende:
Het heeft geen enkele zin een auto_increment ID in een koppeltabel te stoppen. In een koppeltabel vullen de sleutels samen een compound primary key, en daarmee zijn alle combinaties verplicht uniek.

Dat heeft objectification van een relatie in ORM/NIAM. Je geeft een relatie tussen twee of meerdere entiteiten een nieuwe key. Dit houdt in dat voor de combinatie van specifieke values voor alle betrokken entiteiten in de relatie een nieuw uniek gegeven vormt. Wanneer je dit gegeven wilt gebruiken in ANDERE relaties, is het handig deze van een key te voorzien, zodat je met die key relaties aanlegt en niet met bv 4 entiteiten in een relatie. Daarom is objectification bedacht en het heeft in sommige gevallen ZEKER zin. Voorbeeld: project heeft zekere release. Release is objectification van versie + buildnr. Een ander buildnr of andere versie geeft andere release, iets waar je zelfstandig weer mee verder wilt werken, bv in de relatie bug zit in project-release, of bug isfixed in project-release.

Aan de topicstarter zou ik willen adviseren: ga nadenken over wat content is, dus zonder opmaak, en hoe je dat opslaat op een zo flexibel mogelijke manier, zodat je layout technische zaken makkelijk kunt toevoegen aan de, layout-loze, content. Op dit moment lijkt me dat niet het geval.

[Verwijderd]

ik ben ook van mening dat ook in een koppeltabel een unieke id hoort, ook al is de combinatie van de twee sleutels uniek.

Over de scheiding tussen content en opmaak heb ik nog niet nagedacht.
Eigelijk wilde ik de content als html in de db opslaan, zodat iedereen die content post, zelf de opmaak kan regelen (afgezien van stylesheets dan)

[dusty]

Op vrijdag 28 juni 2002 13:04 schreef Otis het volgende:
[..]
Dat heeft objectification van een relatie in ORM/NIAM.
[..]

In de gevallen dat er een extra ID bij wordt gemaakt, is het geen "standaard" koppeltabel meer, maar bijna altijd wordt er meer informatie gekoppeld over die relatie, dus dan zit je sowieso niet met 2 kolommen voor alleen de relaties.

[Verwijderd]

Op vrijdag 28 juni 2002 13:41 schreef dusty het volgende:

[..]

In de gevallen dat er een extra ID bij wordt gemaakt, is het geen "standaard" koppeltabel meer, maar bijna altijd wordt er meer informatie gekoppeld over die relatie, dus dan zit je sowieso niet met 2 kolommen voor alleen de relaties.

Het fenomeen 'koppeltabel' is sowieso niet iets 'standaards'. Je praat nl. t.a.t. over relaties tussen entiteiten. En of je die nu in een tabel stopt met alle velden in de PK, of in een tabel met een extra veld dat de representatie is van de relatie, dat is semantisch gezien hetzelfde: beide keren definieer je een relatie tussen twee of meer entiteiten. Dat mensen dat een 'koppeltabel' noemen moeten zij weten. Dat daar kennelijk ongeschreven regels voor zijn gedefinieerd, het zal.

Ik vind het overigens wel erg grappig dat er 'meer informatie' over een relatie kan worden gekoppeld in 1 tabel. Volgens mij verwar je dan 'relatie tussen entiteiten' met 'relatie tussen tabellen'. Dat laatste is nl. iets niet-bestaands. (ergo: ookal staan velden bijelkaar in een tabel, ze staan daar ivm relaties tussen entiteiten, niet ivm relaties tussen tabellen)