[SQL] foreign key verwijst naar 2 tabellen?

[Verwijderd]

Driftig aan de knutsel met het bouwen van een databeestje loop ik tegen een probleem aan.

Ik heb topics, polls en reacties daarop. Maar hoe slaan we dit netjes op in een RDBMS. Ik zat al moeilijk te doen met sub/superklassen, maar hoe ik er ook tegenaankijk, ik hou altijd het probleem dat de foreign key van de reactie moet verwijzen naar of topics of polls. Dus een verwijzing naar 2 tabellen. En volgens mij kan dit niet.

Wie helpt me uit de brand?

[GrimaceODespair]

Topics en polls moeten allebei hun primary key naar een soort Discussion-tabel mappen. Dan kan je je reacties ook naar diezelfde tabel laten wijzen.

[_Thanatos_]

Over het algemeen heb je dan twee foreign keys, waarbij één van beide NULL moet zijn en de andere naar een correspderend topic/poll verwijst. Met inheritance in de database gaan werken is wel mooi, maar misschien iets over de top voor je grootte van je project?

[Freee!!]

Passen topics en polls in één tabel als je ze een verschillende type-kode als eerste deel van de key geeft? Dan is het echt zo opgelost.

[EfBe]

Verwijderd schreef op 17 januari 2004 @ 20:57:
Driftig aan de knutsel met het bouwen van een databeestje loop ik tegen een probleem aan.

Ik heb topics, polls en reacties daarop. Maar hoe slaan we dit netjes op in een RDBMS. Ik zat al moeilijk te doen met sub/superklassen, maar hoe ik er ook tegenaankijk, ik hou altijd het probleem dat de foreign key van de reactie moet verwijzen naar of topics of polls. Dus een verwijzing naar 2 tabellen. En volgens mij kan dit niet.

Wie helpt me uit de brand?

Poll is een type thread, dus een non-PK field in je startposting record. In feite is dit dus supertype-subtype flattening, je hebt dus een generic 'startpost' supertype en daarvan erf je subtypes (dit is NIAM/ORM taal, geen classes/java/C# blabla ), zoals normalthread-startpost, pollthread-startpost, newsthread-startpost etc.

In feite hebben die nauwelijks extra velden. Je slaat dan alle types plat in 1 table, met een extra field waar je het type aangeeft. Dat hoeft niet in de PK, want je thread is al uniek. Omdat de startpost een startpost is van een poll-thread, is de body een reference naar de feitelijke poll. De thread renderer kijkt naar het type van de posting en rendert op basis daarvan de thread (dus bij een poll gaat hij de body gebruiken om de poll data op te halen).

Valt wel mee hoor, databases . 1 ding goed onthouden: zodra je FK fields hebt die naar meerdere PK's moeten wijzen weet je dat je model fout is. Je kunt bv 3 tables hebben: A, B en C. A.a wijst als FK naar B.b (PK dus) en naar C.c (PK dus). Dit kan niet, maar je kunt wel dan A.a naar B.b laten wijzen en B.b naar C.c, immers door A.a naar 2 PK's te laten wijzen hebben B.b en C.c een 1:1 relatie.

[Verwijderd]

Met het idee van _Thanatos_ kan ik het geheel wel werkend krijgen, maar omdat ik toch wel benieuwd ben naar het hele super/sub-type verhaal wil ik het graag in eerste instantie op die manier proberen.

GrimaceODespair en EfBe willen het volgens mij op de super/sub-type manier oplossen. Ik zie alleen nog niet precies hoe en daarom heb ik het volgende tekeningetje gemaakt, zoals het volgens mij zou moeten zijn.



Nu volg ik op dit moment op school een module over dit gebeuren en daar werd aangegeven dat ik bij deze constructie aparte tabellen moet maken voor poll, topic en news (mandatory, or). Maar dan kom ik dus zowieso het probleem van de FK die verwijst naar meerdere PK's tegen.

Welke tabellen moet ik nu maken? en welke FK verwijst nu naar welke PK?
Wordt thread nu wel een aparte tabel of niet?