Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

[MSSQL] Relaties en inner joins

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik ben al enige tijd bezig met een web applicatie die gegevens uit een database haalt. Ik zal het met een simpel fictief voorbeeld uitleggen. Het idee is redelijk simpel.

Stel ik heb een tabel Huwelijken en een tabel Personen. Normaal gesproken koppelen we tabellen aan elkaar met een koppeltabel als je een many-to-many relatie hebt. In dit geval echter kunnen slechts twee mensen met elkaar getrouwd zijn. Daarom dacht ik dat het makkelijker is om in de tabel Huwelijken twee velden te maken, namelijk Man en Vrouw. Dit zijn dan foreign keys naar de tabel Personen. Deze schets van de situatie is nogmaals fictief en daarom hou ik even geen rekening met homo's ;)

Dus ik heb nu een tabel Huwelijken met de velden Man en Vrouw die beide een relatie hebben met de Personen tabel. Dit werkt. Een alternatief zou dus zijn geweest een tabel Getrouwden, met daarin een relatie naar de Huwelijken, en naar de Personen.

Er zijn meerdere mogelijkheden om gegevens op te vragen. De ene mogelijkheid om de personen als rijen te selecteren met een OR:
SQL:
1
2
3
4
SELECT dbo.Huwelijken.Id, dbo.Personen.Naam
FROM dbo.Huwelijken
INNER JOIN dbo.Personen ON dbo.Huwelijken.[Man Id] = dbo.Personen.Id
OR dbo.Huwelijken.[Vrouw Id] = dbo.Personen.Id


Een mogelijkheid om de personen als kolommen te selecteren:
SQL:
1
2
3
4
SELECT dbo.Huwelijken.Id, Mannen.Naam AS Man, Vrouwen.Naam AS Vrouw
FROM dbo.Huwelijken
INNER JOIN dbo.Personen AS Mannen ON dbo.Huwelijken.[Man Id] = Mannen.Id
INNER JOIN dbo.Personen AS Vrouwen ON dbo.Huwelijken.[Vrouw Id] = Vrouwen.Id

Afhankelijk van wat je wilt (rijen of kolommen) kan je dus selecteren.

Wat denken jullie hiervan? Is dit de goede opzet of is een koppeltabel toch beter? Hoe zit het met de performance bij goed gebruik van indexen? Wellicht goed te vermelden is dat in de echte situatie een van beide velden ook NULL mag zijn, dus in dit voorbeeld mag een Huwelijk ook bestaan uit enkel een Man of een Vrouw.

Het nadeel wat ik alvast tegenkom is dat je geen update en delete rules kunt maken voor beide relaties. Maar dat is een overkomelijk nadeel. Alvast bedankt voor reacties!

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 19-11 14:21

LauPro

Prof Mierenneuke®

Ik zou het generiek houden en spreken van partners, je koppelidee is verder een prima, kan je meteen de ingangsdatum (en scheidings- ;) ) registreren.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Eensch met LauPro; ziet er verder goed uit....
Verwijderd schreef op zondag 17 februari 2008 @ 03:34:
Wellicht goed te vermelden is dat in de echte situatie een van beide velden ook NULL mag zijn, dus in dit voorbeeld mag een Huwelijk ook bestaan uit enkel een Man of een Vrouw.
Ah, maar dan gaan je inner joins niet werken ;)
En even een tikje naar SEA omdat dit toch...euh...een tikje meer SEA is :P

[ Voor 8% gewijzigd door RobIII op 17-02-2008 03:42 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Verwijderd

Topicstarter
Ook een goede nacht ;) Bedankt voor de snelle reacties.

@LauPro: klopt, de namen kunnen in dit voorbeeld beter, maar dit was meer illustratief. De echte situatie gaat over sport en is iets complexer, vandaar deze simpelheid om aan te geven wat ik bedoel.

@Roblll: klopt helemaal. Daar ben ik al aan het stoeien met LEFT OUTER JOIN, en dat werkt dan verder hetzelfde.

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Als je aan 't stoeien bent (en dus nog lerende is mijn conclusie) dan heb je hier misschien nog iets aan: Hoe werken joins?

En verder: Ga eens allemaal naar bed en slapen zeg! :( Pfff...

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Verwijderd

Topicstarter
Bedankt voor de link. Het punt met LEFT OUTER JOIN is dat outer joins niet schijnen te werken met notification based caching van SQL Server 2005. INNER JOIN daarentegen wel, en de eerste query werkt perfect met INNER JOIN:
SQL:
1
2
3
4
SELECT dbo.Huwelijken.Id, dbo.Personen.Naam 
FROM dbo.Huwelijken 
INNER JOIN dbo.Personen ON dbo.Huwelijken.[Man Id] = dbo.Personen.Id 
OR dbo.Huwelijken.[Vrouw Id] = dbo.Personen.Id

Hier kunnen de velden Man Id of Vrouw Id dus NULL zijn mét een INNER JOIN, en notification based caching werkt. Het resultaat is hier dus in de vorm van rijen, en dat komt in mijn geval goed uit.

Maargoed, morgen verder :)

/edit
prachtige context-gerelateerde reclame hier:
Liefde, Mannen & Relaties
Als Je Hier Hebt Gekeken Ben Je Er

Als Vrouw pas Echt Klaar Voor!

[ Voor 17% gewijzigd door Verwijderd op 17-02-2008 14:31 ]

Pagina: 1