[MySQL] Ambiguous field na inner join using (field)?

[Olaf van der Spek]

Weet iemand waarom dit veld in deze query ambiguous is?

code:

mysql> select pid from xcl_players inner join xcl_games_players using (pid);
ERROR 1052: Column: 'pid' in field list is ambiguous

Na een INNER JOIN zijn beide velden toch (gegarandeerd) gelijk aan elkaar en is er toch geen sprake van dubbelzinnigheid?

[nxt]

hij wil graag weten van welke tabel je de pid wilt hebben (ook al zijn ze gelijk)
als je nu eens in plaats van

SQL:

select pid from xcl_players...

doet:

SQL:

select xcl_players.pid from xcl_players...

[ Voor 5% gewijzigd door nxt op 20-04-2004 18:17 ]

[Olaf van der Spek]

Dat snap ik, maar waarom is die niet slim genoeg om door te hebben dat ze gelijk zijn en dat het dus niet uit maakt?

[whoami]

OlafvdSpek schreef op 20 april 2004 @ 23:37:
Dat snap ik, maar waarom is die niet slim genoeg om door te hebben dat ze gelijk zijn en dat het dus niet uit maakt?

Als ik een zaal met 100 mensen toespreek, en er zijn daar 2 OlafvdSpek's, dan ga jij ook niet weten als ik het tegen jou heb, als ik roep dat 'OlafvdSpek naar voor moet komen'.

[Olaf van der Spek]

whoami schreef op 20 april 2004 @ 23:51:
Als ik een zaal met 100 mensen toespreek, en er zijn daar 2 OlafvdSpek's, dan ga jij ook niet weten als ik het tegen jou heb, als ik roep dat 'OlafvdSpek naar voor moet komen'.

Maar de inhoud van de twee velden is identiek, dus maakt het niet uit welke van de twee de server pakt. Toch?

[Creepy]

Je wilt dus dezelfde tabel joinen op hetzelfde veld. Maar hoe moet mysql dat weten? Het is ook perfect mogelijk om dezelfde tabel op verschillende velden te joinen, en jij geeft maar 1 veld op.

[ Voor 11% gewijzigd door Creepy op 21-04-2004 16:11 ]

[Olaf van der Spek]

Creepy schreef op 21 april 2004 @ 16:08:
Je wilt dus dezelfde tabel joinen op hetzelfde veld. Maar hoe moet mysql dat weten? Het is ook perfect mogelijk om dezelfde tabel op verschillende velden te joinen, en jij geeft maar 1 veld op.

Zo is de USING syntax nou eenmaal. Als je ON gebruikt, kun je op verschillende velden joinen.
Het gaat dus over de pin in select pid, niet die in join.

[cameodski]

Als het over de pid in je select-list gaat, geef ik hem groot gelijk. Het algoritme zou aangepast moeten worden enkel en alleen, omdat ze bij een INNER JOIN in combinatie met using toevallig gelijk zijn. Bij een OUTER JOIN hoeven ze bijvoorbeeld al niet meer gelijk te zijn.
Ze kunnen beter hun tijd besteden aan echte bugs.

Ik ben het wel met je eens dat het in deze ene specifieke situatie niet ambiguous is om geen alias/tabelnaam op te geven.

[ Voor 85% gewijzigd door cameodski op 21-04-2004 17:27 ]

[jochemd]

OlafvdSpek schreef op 20 april 2004 @ 18:12:
Weet iemand waarom dit veld in deze query ambiguous is?

code:

mysql> select pid from xcl_players inner join xcl_games_players using (pid);
ERROR 1052: Column: 'pid' in field list is ambiguous

Omdat MySQL zich niet aan de SQL standaard houdt.

Na een INNER JOIN zijn beide velden toch (gegarandeerd) gelijk aan elkaar en is er toch geen sprake van dubbelzinnigheid?

In dit geval van een simpele select niet, maar als je even nadenkt over de definitie van een updateable view kan je vast wel verzinnen waarom het belangrijk is om nog steeds het onderscheid te (kunnen) maken. Alleen hoort door het gebruik van USING die dubbelzinnigheid te verdwijnen.

Hoe het volgens de standaard hoort te werken is als volgt:

code:

Men neme:
CREATE TABLE a (pid VARCHAR(8), naam TEXT);
CREATE TABLE b (pid CHAR(10), plaats TEXT);

SELECT * FROM a INNER JOIN b USING (pid)
Geeft:
pid     a.naam     b.plaats

Of pid uit tabel a of tabel b komt is helemaal niet meer zichtbaar. Sterker nog, met de keuze van datatypes zoals hierboven zal de pid kolom in de resultset het datatype VARCHAR(10) moeten hebben, wat anders is dan zowel het datatype van a.pid als dat van b.pid.

Als je applicatie afhankelijk is van dergelijke subtiliteiten in de SQL standaard heb je met MySQL een bijzonder onfortuinlijke keuze gemaakt.

[cameodski]

jochemd schreef op 21 april 2004 @ 17:28:
Hoe het volgens de standaard hoort te werken is als volgt:

code:

Men neme:
CREATE TABLE a (pid VARCHAR(8), naam TEXT);
CREATE TABLE b (pid CHAR(10), plaats TEXT);

SELECT * FROM a INNER JOIN b USING (pid)
Geeft:
pid     a.naam     b.plaats

En waarom wordt de kolom pid niet twee keer getoond. Als je een OUTER JOIN gebruikt, hoeven deze kolommen niet hetzelfde te zijn. b.pid kan dan namelijk NULL zijn.
Overigens zou een select * gewoon alle kolommen uit beide tabellen moeten geven. Volgens de manual werkt using precies hetzelfde als wanneer je ON gebruikt.
Dus deze twee queries zouden precies hetzelfde moeten doen:

code:

SELECT * FROM a INNER JOIN b USING (b.pid)

code:

SELECT * FROM a INNER JOIN b ON (b.pid = a.pid)

[jochemd]

cameodski schreef op 21 april 2004 @ 17:48:

En waarom wordt de kolom pid niet twee keer getoond.

Omdat de SQL standaard dat zo gedefinieerd heeft.

Volgens de manual werkt using precies hetzelfde als wanneer je ON gebruikt.

Zoals ik alschreef, MySQL is een slechte ongelukkige keuze als je applicatie afhankelijk is van de subtiliteiten van de SQL standaard.
Overigens is het ook niet slim om je afhankelijk te maken van het huidige gedrag van MySQL, want in de ToDo staat dat men van plan is om de hele SQL standaard te implementeren en op dat moment zal het gedrag dus veranderen.

[cameodski]

jochemd schreef op 21 april 2004 @ 17:52:
[...]

Omdat de SQL standaard dat zo gedefinieerd heeft.


[...]

En hoe lost MySQL dat dan op bij een LEFT OUTER JOIN als de ene pid een NULL value heeft?

edit:

Misschien moet ik MySQL maar eens installeren. Dan kan ik die bijzondere features zelf uitproberen.

[ Voor 19% gewijzigd door cameodski op 21-04-2004 17:59 ]

[Olaf van der Spek]

cameodski schreef op 21 april 2004 @ 17:58:
[...]

En hoe lost MySQL dat dan op bij een LEFT OUTER JOIN als de ene pid een NULL value heeft?

SQL:

mysql> SELECT * FROM a INNER JOIN b USING (pid);
+------+------+------+--------+
| pid  | naam | pid  | plaats |
+------+------+------+--------+
| A    | NULL | A    | NULL   |
+------+------+------+--------+
1 row in set (0.00 sec)