[SQL]Foreign Key koppelen aan meerdee tabellen

[Kwistnix]

Een tabel Melding heeft een hardware_id (om aan te geven over welk hardware item de melding gaat). Verder heb ik voor verschillende hardware items aparte tabellen, dus een tabel Pc, Printers etc.
Deze hebben allemaal dus een code.
Nu is het de bedoeling dat hardware_id een foreign key wordt die gekoppeld wordt aan de codes in deze tabellen.
Hoe kan ik dit oplossen, het liefst zonder een hulp tabel aan te maken waar al deze codes in staan.

[momania]

Is iets niet goed gegaan in je ontwerp denk ik..

Wat je beter kan doen is algemene tabel met harware met daarin een type_id , plus
daarnaast dan een tabel met alle type hardware die je wilt hebben...

Dan hoef je geen spinneweb van foreign keys te maken

[Kwistnix]

Jah en laat herschikken van de tabel structuur nou net geen optie zijn
Trouwens een algemene hardware tabel is een andere oplossing, aparte tabellen werkt ook, is niets fouts aan.

[thomaske]

zeker werkt dat ook, maar dan krijg je vroeg of laat (nu dus) problemen

wat je zou kunnen doen is alsnog een koppeltabel maken, met als unieke velden: hardware_id en type_id, deze koppeltabel laat je dan aan je nieuwe tabel koppelen..

[momania]

hoe wil je dat dan met je hardware_id's gaan doen en hoe weet je welk id uit welke tabel komt

Ik bedoel: Je kan niet op een enkel record een foreign key aanmaken naar
een andere tabel..dat gebeurt op de hele kolom...

[Kwistnix]

momania schreef op 14 november 2002 @ 19:56:
hoe wil je dat dan met je hardware_id's gaan doen en hoe weet je welk id uit welke tabel komt

Ik bedoel: Je kan niet op een enkel record een foreign key aanmaken naar
een andere tabel..dat gebeurt op de hele kolom...

Subquery, ik werkt met Oracle, niet MySQL dus dan kan je subqueries gebruiken.

[Kwistnix]

code:

Pc:

Pccode
Processor
Geheugen


Printer:

Printercode
Merk
Type


Melding:

Hardware_id
Omschrijving

Nu is het dus de bedoeling dat Medling.Hardware_id een FK is die verwijst naar de codes uit de tabellen Pc en Printer.

Dit even ter illustratie van mijn vraag.

[Kwistnix]

Doh!
Volgens mij ben ik het probleem verkeerd aan het aanpakken.
Die codes zijn allemaal Primairy Key van hun tabel, maar ze kunnen toch Foreign Key en Primairy Key tegelijk zijn?
Als dat zo is dan kan ik beter de code in elke afzonderlijke tabel als Foreign Key aan Meldingcode koppelen, want dan omzeil ik het hele probleem toch?

[Dash2in1]

FallenAngel666 schreef op 14 November 2002 @ 20:28:
Doh!
Volgens mij ben ik het probleem verkeerd aan het aanpakken.
Die codes zijn allemaal Primairy Key van hun tabel, maar ze kunnen toch Foreign Key en Primairy Key tegelijk zijn?

Volgens mij wel. Kan het op het moment echter niet voor je checken. Probeer het zou ik zeggen, dat heb je blijkbaar niet gedaan
Waarom ben je trouwens niet in de gelegenheid eea te herstructureren?

[ACM]

Ja, tuurlijk kan dat.
Maar het blijft vies en het blijft niet handig, volgens mij.

Btw, als je het andersom toepast, doet het dan nog wel wat je wil??

[Kwistnix]

ACM schreef op 14 november 2002 @ 20:49:
Ja, tuurlijk kan dat.
Maar het blijft vies en het blijft niet handig, volgens mij.

Btw, als je het andersom toepast, doet het dan nog wel wat je wil??

Jah dat is dus even de vraag.
Ik heb dus nu gewoon:

code:

Pccode varchar(10) primary key references Melding(hwitem)

Dit werkt (moet hwitem wel unique zijn natuurlijk) maar of ie nou ook doet wat ie moet doen, dat moet ik even zien te controleren (en volgens mij is dat wel zo want de volgorde van een referentie maakt toch niets uit?).

En ik ben aan het vragen en testen tegelijk, geen zin om op een verlossend antwoord te wachten dus pruts ik zelf ook wat

[maikel]

Als je 't andersom doet, werkt het niet meer zoals je wil volgens mij. Dan draai je dus je 1-op-veel-relatie om: 1 melding kan bij meerdere hardware-items horen.
Ik heb op dit moment ook een database waarbij zoiets voorkomt: contactgegevens kunnen bij een persoon horen, maar ook bij een school of eventueel nog bij een opleiding (andere vestiging bijv.).
Ik heb het opgelost door in de contactgegevens-tabel gewoon 3 FK's te maken: FKPersoonID, FKSchoolID en FKOpleidingID.
Dit werkt op zich goed.
Het enige nadeel is dat de inloggegevens ook in de contactgegevens-tabel staan en je dus steeds, om de bijv. de naam erbij te zoeken, moet uitzoeken of de 'parent' een persoon, een school of een opleiding is. Dus het type van m'n methods Contact.GetParent() is onbekend (oftwel, gewoon 'object').

[Dido]

Je functioneel ontwerp is totaal onafhankelijk van de gebruikte implementatie.
Je hebt nu een entiteit melding die een relatie heeft met 1 of meer entiteiten Hardware. Dat is een fout in je model, en als je dat niet nu aan kunt pakken worden je problemen alleen nog maar erger in de toekomst.
Je hoeft me natuurlijk niet te geloven, maar iedereen die ooit iets heeft geleerd over functioneel ontwerp en normalisering zal het met me eens zijn dat in het beschreven systeem een printer en een pc twee occurences zijn van de entiteit hardware.

Wat is nou eigenlijk de dringende reden dat je je ontwerp helemaal niet meer aan kunt passen?

[Kwistnix]

Even definitie opgezocht van een FK:

Vreemde sleutel is een attribuut of een combinatie van attributen van een tabel waarvan de waarden moeten overeenstemmen met waarden van de primaire sleutel van een andere tabel.

Dit gaat hier dus niet op
Ik zal dus een andere oplossing moeten vinden.

[Kwistnix]

Dido schreef op 14 november 2002 @ 21:17:
Wat is nou eigenlijk de dringende reden dat je je ontwerp helemaal niet meer aan kunt passen?

Je moet gedetailleerde informatie kunnen vastleggen van elk hardware item en dat gaat zo moeilijk met 1 tabel hardware.

[Dido]

Waarom is dat zo moelijk?
Waarom doe je niet iets als dit:

code:

ITEM          ITEMSPEC            SPEC
====          ========            ==========
ID   1-----oo ITEMID       /---1  ID
Naam          SPECID  oo--/       Omschrijving
              Waarde

[Kwistnix]

Dido schreef op 14 November 2002 @ 22:35:
Waarom is dat zo moelijk?
Waarom doe je niet iets als dit:

code:

ITEM          ITEMSPEC            SPEC
====          ========            ==========
ID   1-----oo ITEMID       /---1  ID
Naam          SPECID  oo--/       Omschrijving
              Waarde

Jah, dat zou inderdaad wel kunnen.
Ik ga er eens naar kijken igg.
Maar een FK die verwijst naar meerdere tabellen is dus niet mogelijk?

[thomaske]

FallenAngel666 schreef op 14 november 2002 @ 22:24:
[...]

Je moet gedetailleerde informatie kunnen vastleggen van elk hardware item en dat gaat zo moeilijk met 1 tabel hardware.

Dat kan je ook mooi generiek oplossen hoor. Kan je per item of per soort een aantal attributen invullen

voor meer info [rml][ Database Ontwerp][/rml] (oud topic)

[Dido]

FallenAngel666 schreef op 14 November 2002 @ 22:38:
Jah, dat zou inderdaad wel kunnen.
Ik ga er eens naar kijken igg.
Maar een FK die verwijst naar meerdere tabellen is dus niet mogelijk?

Dan moet je in je FK een tabelnaam op gaan nemen... dus in feite genereer je dan een entiteit tabelnaam.

Het kan, maar als je geen jarenlang en diepgeworteld systeem onder handen krijgt waarin eigenlijk niets meer te veranderen valt zou ik het nevernooit doen.

Stel je eens voor dat je nieuwe soorten hardware krijgt. Dan is het eenvoudiger dat toe te voegen in mijn model (waar je overigens ook nog een tabel zou kunnen toevoegen met "soorten items", maar je kunt ook te ver normaliseren )

Maar nogmaals, teken eerst eens een functioneel datamodel, waarbij je dus geen rekening houdt met details als het al dan niet kunnen toepassen van subqueries, want dat heeft er helemaal niets mee te maken. Als je datamodel goed in elkaar zit kun je een relationele database ook met IBM VSAM in elkaar draaien, dan heb je helemaal geen queries, maar kun je nog steeds alle informatie benaderen!

[Kwistnix]

Dido schreef op 14 November 2002 @ 22:50:
[...]

Dan moet je in je FK een tabelnaam op gaan nemen... dus in feite genereer je dan een entiteit tabelnaam.

Een tabelnaam neem je toch altijd op:

code:

foreign key (hwcode) references Pc(Pccode)

De vraag is hoe krijg ik meerdere tabellen in die reference?

[momania]

FallenAngel666 schreef op 14 november 2002 @ 23:27:
De vraag is hoe krijg ik meerdere tabellen in die reference?

Niet..

Je kan vanuit een tabel niet een foreign key aanmaken naar meerdere tabellen.
Dat worden dan allemaal aparte foreign keys...

Ik zou toch eens goed kijken naar zo'n tussen tabel zoals al eerder voorgesteld is.

Als je het zou willen oplossen op jouw manier, dus met subqueries etc., win je
ook niet echt veel aan performance met de queries die je dan moet gaan maken.
Ook moet je dan een manier verzinnen om dynamisch gegevens uit een andere
tabel te gaan halen en daarbij ook weer de juiste kollommen selecteren.
Beetje te omslachtig naar mijn mening om dat in 1 querie te proberen zowieso.

Ze moet zoveel mogenlijk de overeenstemmende eigenschappen van je hardware
in een hardware tabel zetten en dan dus de detail informatie in een cross reference
tabel stoppen. Je kan natuurlijk dan in je cross reference tabel alles openemen
qua detail informatie bij een bepaald hardware element, maar je hoeft per
hardware item natuurlijk niet alles in te vullen...

[maikel]

Dat kan volgens mij niet. Hoe weet de FK dan nog naar welke tabel hij wijst ?
Stel dat je in de PC-tabel een ID 23 hebt en in de printer-tabel ook een ID 23. Welke van de twee moet het dan zijn ??
Volgens mij is het dan nog het makkelijkst om gewoon twee FK's te maken: eentje voor de PC-tabel en eentje voor de printer-tabel. Hiervan is er dus maar maximaal 1 is ingevuld.

[Kwistnix]

Dus het kan niet.
Nou ja dan regel ik de contraint beveiliging wel in de applicatie hoor.
Tis toch maar een schoolprojectje waarbij niet naar de structuur van de database wordt gekeken maar naar het programma.

[momania]

FallenAngel666 schreef op 15 november 2002 @ 00:02:
Tis toch maar een schoolprojectje waarbij niet naar de structuur van de database wordt gekeken maar naar het programma.

Zo zorg je er wel voor dat je voor je applicatie meer 'eigenlijk overbodige'
code nodig hebt...omdat je de contraints met een goed database ontwerp
kan afvangen.

Dat is natuurlijk ook iets om over na te denken.

[Verwijderd]

Niet genormaliseerde tabellen geven altijd leuke problemen. Dit is een mooi voorbeeldje Het akn werken ja, maar het is zeer onhandig en ingewikkeld.