[DATABASE] Reference Table

[Zyphrax]

Van iemand kreeg ik te horen dat dit een goede techniek is om in een database een relatie te leggen tussen twee entiteiten.

Denk bijvoorbeeld aan boeken, je wilt bij een boek een lijst van gerelateerde boeken opslaan, je zou dan volgens het idee van hem dit doen:

Tabel BoekReferences
ID, Boek1ID, Boek2ID, IsReverse

Als je een reference toevoegd, dan doe je dat door twee records toe te voegen:
ID B1ID B2ID IsReverse
1 5 6 0
2 6 5 1

Je slaat op dat boek Boek 1 (id 5) een relatie heeft met Boek 2 (id 6) en zegt dat dit de heenwaardse relatie is en je slaat de omgekeerde relatie op, met het gegeven dat dit omgekeerd is.

Ligt het aan mij of is dit met het idee van een consistente database erg gevaarlijk en zou:

ID B1ID B2ID
1 5 6

dan al niet voldoende zijn?
Afgezien van het feit dat ik het sowieso geen nette oplossing vind

[whoami]

Als je een relatie hebt tussen boeken, waarom dan geen self-relation op die boeken tabel ? (Tenzij een boek met meerdere boeken kan gerelateerd zijn).

[ Voor 26% gewijzigd door whoami op 04-11-2004 09:05 ]

[Zyphrax]

Laten we zeggen dat een boek met meerdere boeken gerelateerd is.

Maar wat vinden jullie sowieso van de aanpak zelf, dit is toch niet goed omgaan met een database? Een Database docent die ik ken zou zwaar krampen krijgen volgensmij

[whoami]

Het is idd zo dat ik het nut van die 2 records met die 'IsReverse' flag niet zo inzie.

[Zyphrax]

Je database kan gemakkelijk inconsistent raken als je bijvoorbeeld zonder Transactions hier zou werken, vanwege de toevoeging van twee rows.

Een argument voor de dubbele rows (van hem) is dat het, het selecteren makkelijker maakt, omdat je het altijd via 1 kant selecteert. Naar mijn idee is het selecteren op Boek1ID (voor heen) of Boek2ID (voor terug) even gemakkelijk.

[Eelke Spaak]

Ik zou zelfs dat aparte ID-veldje weghalen en simpelweg (boek1Id, boek2Id) als velden gebruiken en daar ook direct een composite primary key van maken.

Zo heb je eigenlijk gewoon een koppeltabel (standaard manier van veel-op-veel relaties weergeven), maar dan koppelt 'ie een tabel met zichzelf.

[Haploid]

Ik ben het eens met Eelke: het is voldoende als je alleen Boek1ID en Boek2ID overhoudt en daar de primary key van maakt. Je kunt overigens uit die tabel net zo makkelijk weer je oude structuur tevoorschijn toveren door:

select Boek1ID, Boek2ID, 0 as IsReverse
union
select Boek2ID, Boek1ID, 1 as IsReverse

Goed, dan mis je nog dat ID veld, maar dat bevat toch geen informatie.

[Verwijderd]

Hoewel een structuur Boek1ID, Boek2ID genoeg is, zijn er genoeg voorbeelden te bedenken waar het wel handig is om 2 records op te slaan.

Het is namelijk niet altijd zo dat de relatie omkeerbaar is. Hoewel Boek1 gerelateerd kan zijn aan boek 2 hoeft Boek 2 niet automatisch ook gerelateerd te zijn aan Boek 1.

(Boeken zijn hier een onhandig voorbeeld maar het zou duidelijk genoeg moeten zijn )

[Zyphrax]

Ik snap dan niet waarom je het in zo'n structuur op zou slaan.

Kan je een voorbeeld benoemen, waar je geen omgekeerde relatie zou willen en het wel op deze wijze opslaan?

Bovendien zie je het dan als twee verschillende relaties, in dit voorbeeld worden de gegevens van 1 relatie volgensmij domweg dubbel opgeslagen.

[ Voor 32% gewijzigd door Zyphrax op 04-11-2004 21:01 ]

[Haploid]

Verwijderd schreef op 04 november 2004 @ 20:04:
Hoewel een structuur Boek1ID, Boek2ID genoeg is, zijn er genoeg voorbeelden te bedenken waar het wel handig is om 2 records op te slaan.

Het is namelijk niet altijd zo dat de relatie omkeerbaar is. Hoewel Boek1 gerelateerd kan zijn aan boek 2 hoeft Boek 2 niet automatisch ook gerelateerd te zijn aan Boek 1.

(Boeken zijn hier een onhandig voorbeeld maar het zou duidelijk genoeg moeten zijn )

Maak er dan van een tabel met (Boek1ID, Boek2ID, Omkeerbaar), waarbij die laatste aangeeft dat de relatie ook de andere kant op werkt (default 1).

[Verwijderd]

Maak er dan van een tabel met (Boek1ID, Boek2ID, Omkeerbaar), waarbij die laatste aangeeft dat de relatie ook de andere kant op werkt (default 1).

Dat is niet handig als beide relaties Boek1 -> Boek2 en Boek2 -> Boek 1 onafhankelijk zijn. Op het moment dat je een relatie wilt toevoegen of verwijderen moet je constant gaan zoeken naar wat er in de database staat
Je krijgt dan heel veel verschillende situaties die je steeds anders moet afhandelen.

Gewoon de records
Boek1 Boek2 en
Boek2 Boek1 (Waar nodig)
opslaan is vele malen simpeler.

Wil je er een toevoegen: recordje aanmaken.
Wil je er een verwijderen: recordje verwijderen.

[Kwistnix]

En wat als je informatie over de relatie zelf wilt opslaan?
Dus niet alleen aangeven dat er een relatie bestaat, maar wat die relatie inhoudt?
Dan is een simpele koppeltabel die bestaat uit 2 kolommen met id's niet genoeg.
Dit zou bijvoorbeeld relevant kunnen zijn in het geval van een CMDB.

[ Voor 3% gewijzigd door Kwistnix op 05-11-2004 00:05 ]