[mysql]probleem met JOIN

[Megamind]

Ik heb deze query:

code:

mysql_query("SELECT * FROM planning INNER JOIN medewerkplan 
WHERE medewerkplan.mid='$login->perskey' 
AND medewerkplan.eid=planning.id")

Het is de bedoeling dat hij alle velden selecteerd uit Planning waar in de tabel Medewerkplan de MID gelijk is aan de ingelogde persoon én de eid gelijk is aan de ID die op dat moment opgevraagd wordt door de planning...

Dan zou ik een output moeten krijgen met alle planningen waar een medewerker staat ingedeeld (indelingen staan in Medewerkplan), maar ik krijg juist degene te zien waar hij juist niet ingedeeld staat

Ik snap nog niet zoveel van joins, wie ziet of ik iets fout doet?

Dit zijn mijn 2 tabellen:

code:

planning:
| ID | datum | tijden |

Medewerkplan:

| ID | mid | eid | status |

[ Voor 13% gewijzigd door Megamind op 30-06-2004 15:25 ]

[gorgi_19]

Je syntax is fout; je geeft niet aan waarop gejoined moet worden.

Zie bijvoorbeeld: P&W FAQ - SQL en www.w3schools.com/sql voor een uitleg over het gebruik van Joins.

[gorgi_19]

whoami wilde nog wat toevoegen aan dit topic.

Of je schrijft je query zo:

code:

select *
from planning
inner join medewerkplan ON medewerkplan.eid = planning.id where mid = ...

of zo:

code:

select *
from planning, medewerkplan
where medewerkplan.eid = planning.id
and medewerkplan.mid = ...

[curry684]

Als je dan wat toevoegt doe het dan goed

Die 2 syntaxes zijn dus identiek in betekenis, het staat je vrij te kiezen welke je gebruikt. Echter, de eerste variant is flexibeler aan te passen mocht je het join-type later willen veranderen, de 2e is namelijk per definitie een INNER JOIN. Daarnaast is de 2e variant redelijk snel onleesbaar zodra je 3 of meer tabellen gaat joinen.

[gorgi_19]

Dan vechten jullie het maar even met z'n tweeen uit...
open

[whoami]

curry684 schreef op 30 juni 2004 @ 09:27:
Als je dan wat toevoegt doe het dan goed

Die 2 syntaxes zijn dus identiek in betekenis

Dat was ook de bedoeling. De topicstarter post een query die een mix is van mijn eerste en tweede optie; daarom post ik de twee mogelijkheden die beiden tot hetzelfde resultaat leiden.

Echter, de eerste variant is flexibeler aan te passen mocht je het join-type later willen veranderen, de 2e is namelijk per definitie een INNER JOIN

De tweede variant is ook makkelijk aan te passen; als je een OUTER JOIN wilt, dan maak je gebruik van (+):

code:

select * 
from personen, orders
where personen.persoon_id = orders.order_id (+)

Ik dacht dat die (+) ook standard was, dus dat zou normaal geen probleem mogen zijn.
Dat de eerste variant leesbaarder is, is wel waar.

Daarnaast is de 2e variant redelijk snel onleesbaar zodra je 3 of meer tabellen gaat joinen.

Hmm.... da's gewoon een kwestie van smaak, en hoe je die 2de query precies uitschrijft:

code:

select *
from tabel1,
     tabel2,
     tabel3,
     tabel4
where ...

valt wel redelijk mee.

[curry684]

whoami schreef op 30 juni 2004 @ 09:39:
[...]


Dat was ook de bedoeling. De topicstarter post een query die een mix is van mijn eerste en tweede optie; daarom post ik de twee mogelijkheden die beiden tot hetzelfde resultaat leiden.

Weet ik, maar het stond er niet bij

[...]

De tweede variant is ook makkelijk aan te passen; als je een OUTER JOIN wilt, dan maak je gebruik van (+):

code:

select * 
from personen, orders
where personen.persoon_id = orders.order_id (+)

Ik dacht dat die (+) ook standard was, dus dat zou normaal geen probleem mogen zijn.
Dat de eerste variant leesbaarder is, is wel waar.

Die (+) notatie zegt mij niets, maar dat is neem ik aan een FULL OUTER JOIN in Oracle oid? En hoe doe je dan een left of right?

SQL Server vind er overigens Incorrect syntax near ')' van

[...]

Hmm.... da's gewoon een kwestie van smaak, en hoe je die 2de query precies uitschrijft:

code:

select *
from tabel1,
     tabel2,
     tabel3,
     tabel4
where ...

valt wel redelijk mee.

Het probleem is dat je de tabel en de bijbehorende join-conditie scheidt. In deze vorm is de rij van tabellen zelf overzichtelijker, maar moet je de conditie er nog steeds X regels verder bijzoeken. Met als bijkomend probleem dat je tussen non-joining condities moet zoeken omdat alles in de where-clause verzamelt.

[whoami]

curry684 schreef op 30 juni 2004 @ 09:45:
[...]


Die (+) notatie zegt mij niets, maar dat is neem ik aan een FULL OUTER JOIN in Oracle oid? En hoe doe je dan een left of right?

SQL Server vind er overigens Incorrect syntax near ')' van

Het is geen FULL OUTER JOIN, maar een OUTER JOIN op de tabel waar het +-je naast staat, in dit geval dus op orders.

Ik dacht dat Sql Server ook zoiets kende; ff opzoeken....

Het is wel zo dat ik ook wel de 'JOIN' syntax gebruik in Sql Server.

Het probleem is dat je de tabel en de bijbehorende join-conditie scheidt. In deze vorm is de rij van tabellen zelf overzichtelijker, maar moet je de conditie er nog steeds X regels verder bijzoeken. Met als bijkomend probleem dat je tussen non-joining condities moet zoeken omdat alles in de where-clause verzamelt.

Idd, je hebt hier wel gelijk in.

[whoami]

In SQL Server is het dus blijkbaar zo:

code:

SELECT * FROM tabel1, tabel2
WHERE tabel1.id *= tabel2.id

Echter, ik vond ook dit op SQL Team dacht ik:

If this is SQL 7 or SQL 2k then Books online states that you should not use the *= (t-sql joins). It goes on to say that all T-SQL joins should be changed to the SQL-92 standard, as NR suggested. I had done testing with this a few years ago and noted that the SQL-92 joins are faster than T-SQL joins.

This may not be an option for you though if you are using SQL 6.5. I dont know if 6.5 even had SQL-92 joins.

In any case, type *= into the keyword find under the INDEX tab in books online and you will find the entry for "*= operator" that explains the newer syntax.


Daniel
SQL Server DBA

De JOIN - versie van die query zou dus ook sneller zijn. _{Zelf niet getest}

[curry684]

whoami schreef op 30 juni 2004 @ 09:55:

De JOIN - versie van die query zou dus ook sneller zijn. _{Zelf niet getest}

Volgens Query Analyzer op SQL2k zijn ze even snel, ik heb echter geen grote tabellen nu bij de hand om een echte benchmark te doen. De syntax werkt iig wel voor left en right outer joins (*= en =*), maar *=* voor een full werkt niet....

[ACM]

whoami schreef op 30 juni 2004 @ 09:39:
De tweede variant is ook makkelijk aan te passen; als je een OUTER JOIN wilt, dan maak je gebruik van (+):

Dat is de Oracle-manier. SQL-standaard roept alleen (NATURAL) (LEFT/RIGHT/FULL OUTER)/(INNER) JOIN als de manier voor joins.

Sybase en MSSQL hebben indertijd *= en =* gebruikt voor left/right outer joins. Die DB-specifieke notaties zijn geloof ik van de tijd dat JOIN's nog niet in de specificatie bestonden (SQL86 oid?)

De JOIN - versie van die query zou dus ook sneller zijn. _{Zelf niet getest}

Dat hangt natuurlijk er van af wat de query-analyzer ervan kan maken, een outer join is niet perse sneller dan een inner join en een expliciete join kan naar exact hetzelfde executieplan worden omgezet als een impliciete join
Dat zal dus per DB verschillen.

edit:

En zo gooi ik een deel van mijn eigen reactie weg

[ Voor 71% gewijzigd door ACM op 30-06-2004 10:35 ]

[whoami]

curry684 schreef op 30 juni 2004 @ 10:27:
[...]

Volgens Query Analyzer op SQL2k zijn ze even snel, ik heb echter geen grote tabellen nu bij de hand om een echte benchmark te doen. De syntax werkt iig wel voor left en right outer joins (*= en =*), maar *=* voor een full werkt niet....

Ik denk dat je een FULL met een **= moet doen.

[whoami]

ACM schreef op 30 juni 2004 @ 10:32:
[...]

Dat is de Oracle-manier. SQL-standaard roept alleen (NATURAL) (LEFT/RIGHT/FULL OUTER)/(INNER) JOIN als de manier voor joins.

Sybase en MSSQL hebben indertijd *= en =* gebruikt voor left/right outer joins. Die DB-specifieke notaties zijn geloof ik van de tijd dat JOIN's nog niet in de specificatie bestonden (SQL86 oid?)

OK.
Was er dan voor de JOIN clause geen enkele standard manier om OUTER JOINS te specifieren?

[curry684]

whoami schreef op 30 juni 2004 @ 10:36:
[...]

Ik denk dat je een FULL met een **= moet doen.

Line 3: Incorrect syntax near '*='.

Volgens BOL:

In earlier versions of Microsoft® SQL Server™ 2000, left and right outer join conditions were specified in the WHERE clause using the *= and =* operators. In some cases, this syntax results in an ambiguous query that can be interpreted in more than one way. SQL-92 compliant outer joins are specified in the FROM clause and do not result in this ambiguity. Because the SQL-92 syntax is more precise, detailed information about using the old Transact-SQL outer join syntax in the WHERE clause is not included with this release. The syntax may not be supported in a future version of SQL Server. Any statements using the Transact-SQL outer joins should be changed to use the SQL-92 syntax.

The SQL-92 standard does support the specification of inner joins in either the FROM or WHERE clause. Inner joins specified in the WHERE clause do not have the same problems with ambiguity as the Transact-SQL outer join syntax.

Lijkt er dus op dat er geen short-hand syntax voor FULL OUTER JOIN was...?

[whoami]

ANSI join syntax lets you specify a type of join that wasn't possible in the old-style syntax, the full OUTER JOIN.

Als ik eigenlijk eerlijk mag zijn, een FULL OUTER JOIN heb ik nog nooit gebruikt.

[Megamind]

oi niet eens gezien dat ie weer open was

Ik heb het zo opgelost

code:

mysql_query("SELECT planning.* FROM planning ". 
            "LEFT JOIN medewerkplan ON planning.id=medewerkplan.eid ". 
            "WHERE medewerkplan.mid='$login->perskey' ". 
            "AND planning.datum>=$vandaagdag ".
            "ORDER BY planning.datum ASC, planning.tijdbegin ASC ")

[ Voor 17% gewijzigd door curry684 op 30-06-2004 14:24 . Reden: newlines :X ]

[curry684]

Mag ik vragen waarom je een LEFT JOIN gebruikt? Of is het de bedoeling dat je dingen kunt plannen zonder dat iemand ze gaat doen?

[Megamind]

curry684 schreef op 30 juni 2004 @ 14:23:
Mag ik vragen waarom je een LEFT JOIN gebruikt? Of is het de bedoeling dat je dingen kunt plannen zonder dat iemand ze gaat doen?

ja Ik wil dat er geen gegevens van de medewerkplan gehaald kan worden, die worden later opgehaald, klinkt niet zo efficient maar dat komt omdat je met een keuzemenu eigenlijk kiest uit verschillende queries...