[SQL] database ontwerp

[amoen]

Ik ben in dubio hoe ver ik moet gaan om een abstracte join table (voor in een CMS) op te zetten om voor verschillende entiteiten een één-op-meer relatie te kunnen maken.

Ik wil met een generieke join-table alle soorten koppelingen maken die ik normaal zou doen met een referentie-key in de table zelf.

Hieronder mijn idee:
table: page

page_id	page_title	page_body	page_date
1	home	...	...
2	contact	...	...
3	privacy	...	...

table: join

join_key	join_master	join_slave
page_children	1	2
page_children	1	3

In de bovenstaande join-table weet ik aan de hand van de join_key dat 'contact' en 'privacy' children zijn van 'home'. Ik kan op deze manier nog veel meer relationele data opslaan in die tabel:

table: join

join_key	join_master	join_slave
page_author	1	12
page_header_img	1	87

Ik weet nu de autheur en de hoofdafbeelding van 'home': user_id=12 en file_id=87

Doen meer mensen dit? Is het handig? Gaan al die joins (afgezien van de juiste INDEXES) mijn performance aanzienlijk verslechteren? Mij persoonlijk lijkt dit een hele handig model, afgezien van de grote queries die ik moet gaan schrijven... ik hou alle entiteit-tabellen schoon van referenties. En mocht ik beslissen om in de toekomst 2 tabellen te joinen hoef ik hun individuele structuur niet te wijzigen, maar verzin ik gewoon een nieuwe unieke join_key voor de join-table.

[Orion84]

Waarom 1 join tabel met verschillende relatie types, in plaats van 1 join tabel per relatie?

Op deze manier moet je bij een join steeds ook nog filteren op het relatietype.

Ik heb weinig praktijkervaring met database ontwerp, maar de constructie die jij voorstelt ben ik in mijn informatica colleges over databases nooit tegengekomen.

Relaties buiten de entity tabellen houden, ook wel normaliseren genoemd volgens mij, is heel normaal in de database wereld, maar dan volgens mij altijd met 1 tabel per relatie.

Het voordeel van een aparte tabel voor elke relatie is ook dat je dan in die tabel nog specifieke attributen kan opnemen voor die relatie. Met een generieke join tabel wordt dat een beetje lastig.

[ Voor 16% gewijzigd door Orion84 op 19-08-2012 14:37 ]

[CodeCaster]

Ik wil met een generieke join-table alle soorten koppelingen maken die ik normaal zou doen met een referentie-key in de table zelf. [...] ik hou alle entiteit-tabellen schoon van referenties. En mocht ik beslissen om in de toekomst 2 tabellen te joinen hoef ik hun individuele structuur niet te wijzigen, maar verzin ik gewoon een nieuwe unieke join_key voor de join-table.

Waarom? Referenties zijn niet eng. Onnodig lange query's met tabel- of kolomnamen in strings zijn dat wel.

Ik weet nu de autheur en de hoofdafbeelding van 'home': user_id=12 en file_id=87

En dat weet je met de kolommen author_id en mainimage_id in de tabel page ook. Zodra je kolom- of tabelnamen in rijen in een andere tabel gaat zetten, ben je bezig met een database-in-database oftewel het inner platform effect.

Voor een veel-op-veelrelatie (meerdere auteurs van een pagina, meerdere pagina's per auteur) kun je wel een dergelijke constructie gebruiken, maar dan alsnog in de vorm van page_author_link met de kolommen page_id en author_id.

Waarom? Omdat foreign keys.

[ Voor 32% gewijzigd door CodeCaster op 19-08-2012 15:01 ]