[Database] relaties

[vinnux]

Database : MYSql

Table A
id int
B0 -> Table B id
B1 -> Table B id
B2 -> Table B id
Data :
1,1,2,3
2,2,3,4

Table B
id int
name varchar(255)
Data:
1,één
2,twee
3,drie
4,vier


Hoe kan ik nu eeb query maken die alle b.name toont van table a?
bijvoorbeeld
1,één,twee,drie
Dit zal wel niet werken:
SELECT a.id, b.name, b.name, b.name FROM a,b WHERE a.B0 = b.id AND a.B1 = b.id AND a.B2 = b.id

Graag wil ik het op deze manier en op geen andere. Wanneer het niet mogelijk blijkt te zijn, zoek ik naar een andere oplossing.

[ Voor 11% gewijzigd door vinnux op 02-09-2003 10:28 ]

[ATS]

Bovenstaande werkt inderdaad niet, maar dat heb je kennelijk niet eens zelf geprobeerd... Pak er eens een boek of tutorial over SQL bij zou ik zeggen, want dat heb je kennelijk nog niet geprobeerd.
Bovenstaande levert alleen een resultaat als B0, B1 en B2 hetzelfde zijn, en dat is neem ik aan niet de bedoeling.

[ Voor 32% gewijzigd door ATS op 02-09-2003 10:32 ]

[vinnux]

Ik heb alleen een simpeler/eenvoudiger voorbeeld gemaakt en oeps toen iets vergeten.

[ Voor 9% gewijzigd door vinnux op 02-09-2003 10:33 ]

[Verwijderd]

Wat je nodig hebt is een inner join statement in SQL, alleen MySQL ondersteund geen inner joins. Dus hoe je het op kunt lossen is een recordset aanmaken met de gevonden waarden uit de ene tabel, en die vergelijken met de waarden in een recordset uit een andere tabel.

Voor meer informatie over recordsets: www.w3schools.com

[vinnux]

MySql geen innerjoins?
http://www.mysql.com/doc/en/JOIN.html

[ATS]

Er zijn twee opties:
1) tabel b meer dan één keer in de from opnemen met een alias (FROM a, b AS b1, b AS b2...). Nu kan je b1 en b2 gebruiken in de rest van je query, zodat je where statement gaat kloppen (ik weet niet zeker of MySQL dat ondersteund trouwens)
2) joins gebruiken.

Optie 2 is veel efficienter. Als je niet weet hoe je zo'n statement maakt, dan kan het erg leerzaam zijn om eens wat te klooien met een systeem waar je grafisch queries kan maken, en daarna het resultaat te bekijken. Ze zijn niet altijd even elegant, maar wel inzichtelijk. Opties zijn a.o. Microsoft Access op Windows of Kexi op KDE.

[ Voor 6% gewijzigd door ATS op 02-09-2003 10:38 . Reden: kleine aanvulling ]

[vinnux]

Werkt

code:

SELECT a.id, b_0.name, b_1.name, b_2.name
FROM a, b b_0, b b_1, b b_2
WHERE b_0.id = a.b0 AND b_1.id = a.b1 AND b_2.id = a.b2

code:

SELECT a.id, b_0.name, b_1.name, b_2.name
FROM a
INNER JOIN b b_0 ON ( b_0.id = a.b0 ) 
INNER JOIN b b_1 ON ( b_1.id = a.b1 ) 
INNER JOIN b b_2 ON ( b_2.id = a.b2 )

Maar waarom deze sneller zou zijn ontgaat mij in het geheel.

[ Voor 43% gewijzigd door vinnux op 02-09-2003 10:46 ]

[Verwijderd]

Sorry.. ik heb mij vergist. Alleen nested inner joins doet ie niet.

[vinnux]

Maar het blijft feitelijk gezien een vieze oplossing. Er is hier sprake van N op N relaties. I*n dit geval kan B tot meerdere A behoren (N op N) maar A moet 3 B bevatten (N op 3), dus eigenlijk moet je hier een aparte koppelingstabel voor maken. Maar ja voor drie is dat wel wat veel van het goede vind ik.

[vinnux]

Verwijderd schreef op 02 September 2003 @ 10:48:
Sorry.. ik heb mij vergist. Alleen nested inner joins doet ie niet.

Nested doet MySql zo een beetje niks (versie 3 dan )

[ATS]

Optie één doet eigenlijk het volgende: maak een tabel met alle combinaties van a, b, b en b. Dat wordt dus een tabel met a*b³ tuples. Daarna wordt bekeken welke tuples aan de voorwaarden voldoen. Als b (en a) groot worden, dan loopt dat nogal uit de hand...
Een JOIN werkt efficiënter, hierbij worden beide tabellen gesorteerd op de joinconditie (als er geen index is), en worden de matchende tuples ingevoegd. In jouw geval moet je dus ZEKER zorgen voor een index op b.ID! Overigens is de preciese route die je query-optimizer pakt natuurlijk afhankelijk van hoe de optimizer precies werkt.

[ Voor 1% gewijzigd door ATS op 02-09-2003 10:58 . Reden: kleine verduidelijking ]

[vinnux]

Maar als ik dus simpel door redeneer kun je beter nooit een WHERE clausule gebruiken wanneer je tabellen aan elkaar koppelt. Misschien denk ik nu te snel, maar bijna alle WHERE statements zijn om te bouwen naar INNER JOIN statements

[ Voor 4% gewijzigd door vinnux op 02-09-2003 11:04 ]

[ATS]

AFAIK: ja, dat klopt.

[Creepy]

ATS schreef op 02 September 2003 @ 10:53:
Optie één doet eigenlijk het volgende: maak een tabel met alle combinaties van a, b, b en b. Dat wordt dus een tabel met a*b³ tuples. Daarna wordt bekeken welke tuples aan de voorwaarden voldoen. Als b (en a) groot worden, dan loopt dat nogal uit de hand..,Een JOIN werkt efficiënter, hierbij worden beide tabellen gesorteerd op de joinconditie (als er geen index is), en worden de matchende tuples ingevoegd. In jouw geval moet je dus ZEKER zorgen voor een index op b.ID! Overigens is de preciese route die je query-optimizer pakt natuurlijk afhankelijk van hoe de optimizer precies werkt.

Nou weet ik niet over welke aftandse Optimizer jij het hebt maar voor de gemiddelde Optimizer gaat bij die where condities echt niet een compleet cartegiaans produkt maken en dan pas a.d.h.v. de where conditie er tupels uitgooien, maar zal hetzelfde doen als dat met een JOIN. Een where tabel1.id = table2.id is namelijk gewoon een join. OF je nu wel of niet het statement JOIN gebruikt maakt voor de gemiddelde optimizer echt niet uit.