sql geeft 2 rijen terug in plaats van 1

[Verwijderd]

code:

                SELECT 
                    sessions.sessionid,
                    sessions.aid,
                    sessions.kid,
                    sessions.fid,
                    sessions.aantal,
                    artikelen.naam,
                    artikelen.prijs,
                    kleuren.kleur,
                    formaten.hoogte,
                    formaten.breedte,
                    formaten.diepte,
                    partnerartikelen.prijs AS pprijs
                FROM 
                    sessions
                LEFT JOIN
                    artikelen
                ON
                    sessions.aid = artikelen.id
                LEFT JOIN
                    kleuren
                ON
                    sessions.kid = kleuren.id
                LEFT JOIN
                    formaten
                ON
                    sessions.fid = formaten.id
                LEFT JOIN
                    partnerartikelen
                ON
                    partnerartikelen.aid = artikelen.id
                WHERE
                    sessions.sessionid = 'sessieidenzo'

Bij deze query geeft sql 2 rijen terug, nl een rij waarbij pprijs NULL is en waarbij pprijs een waarde heeft. Dit terwijl aid maar 1x voorkomt in de tabel. Nu snap ik niet waarom hij nu 2 rijen laat zien, want hij zou eigenlijk alleen 1 rij moeten laten zien waarbij alleen de daadwerkelijke waarde van pprijs zal worden weergeven (dus of NULL of een getal, niet beide).

[NMe]

Outer joins betekenen dat je een bepaald record uit de ene tabel wil linken aan elk record in een andere volgens je join-criteria. Ik gok dat tenminste één van je LEFT JOIN's een INNER JOIN moet worden.

[BalusC]

En wat als je INNER JOIN gebruikt? (of gewoon een WHERE clause).

SQL:

SELECT 
    sessions.sessionid,
    sessions.aid,
    sessions.kid,
    sessions.fid,
    sessions.aantal,
    artikelen.naam,
    artikelen.prijs,
    kleuren.kleur,
    formaten.hoogte,
    formaten.breedte,
    formaten.diepte,
    partnerartikelen.prijs AS pprijs
FROM 
    sessions,
    artikelen,
    kleuren,
    formaten,
    partnerartikelen
WHERE
    sessions.aid = artikelen.id
AND
    sessions.kid = kleuren.id
AND
    sessions.fid = formaten.id
AND
    partnerartikelen.aid = artikelen.id
AND
    sessions.sessionid = 'sessieidenzo'

[ Voor 5% gewijzigd door BalusC op 10-07-2006 15:41 ]

[whoami]

Het valt me trouwens op dat veel mensen 'zomaar' , te pas en te onpas LEFT JOINS gaan gebruiken. Echter, een LEFT JOIN is zowiezo trager dan een INNER JOIN, dus, gebruik enkel een LEFT of RIGHT (iig , een OUTER ) join als je weet dat je dat nodig hebt.
Dan zal je zowiezo niet tegen dergelijke situaties aanlopen.

Dus: neem er eens een manual bij, en lees eens wat het vershcil is tussen een left , right, full en inner join.

[Verwijderd]

Hmmm, zonder joins krijg ik helemaal geen waarde terug. Ben al even bezig geweest met inner joins, maar als ik de laatste en/of eerste left join verander in een inner join blijft het resultaat hetzelfde. Als ik de overige vervang krijg ik geen waarde terug...

[PhysicsRules]

Vanaf welke kolom heb je NULL's. Dat is een mooie hint bij welke join het fout gaat. In die vorige tabel zitten dan meerdere entries die naar je sessionid verwijzen.

[Verwijderd]

De waarde NULL wil niet zeggen dat hij de waarde niet heeft verkregen, een aantal kolommen kunnen nl gewoon echt de waarde NULL hebben... Waar het misgaat is de kolom PPRIJS. Deze is soms NULL en soms niet. Dat is ook correct, maar als partnerartikelen.pprijs is gezet (dus niet NULL), dan laat hij 2 rijen zien waarbij beide rijen hetzelfde zijn behalve dat kolom pprijs bij de ene wel NULL is en de ander niet.

[BalusC]

Oh, dan doe je toch gewoon WHERE pprijs != NULL ?

Kennelijk heb je ook daadwerkelijk meerdere rijen en heb je een foutje gemaakt bij het zetten van de pprijs, bijvoorbeeld een INSERT in plaats van een UPDATE. Kijk eens in je partnerartikelen DB

[ Voor 12% gewijzigd door BalusC op 10-07-2006 16:02 ]

[Verwijderd]

BalusC schreef op maandag 10 juli 2006 @ 16:02:
Oh, dan doe je toch gewoon WHERE pprijs != NULL ?

Kennelijk heb je ook daadwerkelijk meerdere rijen en heb je een foutje gemaakt bij het zetten van de pprijs, bijvoorbeeld een INSERT in plaats van een UPDATE. Kijk eens in je partnerartikelen DB

Nee, pprijs is soms nl wel NULL en dat is correct...! Als die wel NULL is laat hij overigens wel netjes 1 rij zien, alleen als hij niet NULL is laat hij 2 rijen zien.

[PhysicsRules]

is artikelID zeker uniek in partnerartikelen?

[Verwijderd]

PhysicsRules schreef op maandag 10 juli 2006 @ 16:15:
is artikelID zeker uniek in partnerartikelen?

nee...

[moozzuzz]

Verwijderd schreef op maandag 10 juli 2006 @ 16:20:
nee...

Neen als in niet uniek gedefinieerd, maar in praktijk normaal wel, of als in er staan 2x een koffiepot met id=5 tussen?

In het eerste geval: Ergens toch een foute input gehad in het verleden
In het tweede geval: Waarom?

[Verwijderd]

moozzuzz schreef op maandag 10 juli 2006 @ 16:37:
[...]
In het tweede geval: Waarom?

Omdat meerdere partners dezelfde artikelen kunnen hebben...

[P_de_B]

whoami schreef op maandag 10 juli 2006 @ 15:43:
Het valt me trouwens op dat veel mensen 'zomaar' , te pas en te onpas LEFT JOINS gaan gebruiken. Echter, een LEFT JOIN is zowiezo trager dan een INNER JOIN, dus, gebruik enkel een LEFT of RIGHT (iig , een OUTER ) join als je weet dat je dat nodig hebt.
Dan zal je zowiezo niet tegen dergelijke situaties aanlopen.
.

Sowieso trager lijkt me overdreven, dat is nogal sterk afhankelijk van welke indexen etc gebruikt worden. Er is wel kans dat een inner join sneller is.

---

De keuze tussen een inner of outer join is zo fundamenteel dat je die m.i. alleen op basis van gewenste functionaliteit moet maken niet op basis van de verwachte snelheid.

[Suaver]

BalusC schreef op maandag 10 juli 2006 @ 16:02:
Oh, dan doe je toch gewoon WHERE pprijs != NULL ?

Kennelijk heb je ook daadwerkelijk meerdere rijen en heb je een foutje gemaakt bij het zetten van de pprijs, bijvoorbeeld een INSERT in plaats van een UPDATE. Kijk eens in je partnerartikelen DB

De LEFT JOIN die de TS gebruikt. Returneerd alle rijen van de eerste tabel, ook al zijn er geen matches met de tweede tabel.

[PhysicsRules]

Verwijderd schreef op maandag 10 juli 2006 @ 16:20:
[...]

nee...

Komt je artikel dan niet twee keer voor in die tabel? Een keer met en een keer zonder prijs?

[Verwijderd]

Suaver schreef op maandag 10 juli 2006 @ 16:45:
[...]

De LEFT JOIN die de TS gebruikt. Returneerd alle rijen van de eerste tabel, ook al zijn er geen matches met de tweede tabel.

Dat klopt, dat is ook de bedoeling Echter doet hij dat dus niet helemaal en loopt het stuk op de pprijs. Als ik de join met partnerartikelen eruit haal dan werkt het wel, maar ik heb die pprijs helaas wel nodig...

PhysicsRules schreef op maandag 10 juli 2006 @ 16:48:
[...]

Komt je artikel dan niet twee keer voor in die tabel? Een keer met en een keer zonder prijs?

Nee, de artikelen zelf staan in de tabel artikelen. in de partnerartikelen tabel staan alleen de koppelingen van welke artikelen uit de artikelen tabel toegwezen zijn aan de betreffende partner in de partner tabel.

[ Voor 56% gewijzigd door Verwijderd op 10-07-2006 16:52 ]

[whoami]

P_de_B schreef op maandag 10 juli 2006 @ 16:41:
[...]

De keuze tussen een inner of outer join is zo fundamenteel dat je die m.i. alleen op basis van gewenste functionaliteit moet maken niet op basis van de verwachte snelheid.

Dat ben ik met je eens.

[PhysicsRules]

Kun je die output eens geven?

[Verwijderd]

PhysicsRules schreef op maandag 10 juli 2006 @ 16:53:
Kun je die output eens geven?

code:

sessionid aid kid fid aantal naam     prijs    kleur           hoogte   breedte  diepte   pprijs
et4s3g  13 32   0 1     AEG-F505  175.00  donkerblauw   NULL    NULL    NULL    NULL
et4s3g  13 32   0 1     AEG-F505  175.00  donkerblauw   NULL    NULL    NULL    139.00

In de code heb ik het zo gemaakt, dat als er geen pprijs is bij een artikel, dan gebruikt hij het veld prijs. Dit omdat sommige partners bij sommige artikelen een aangepaste prijs (korting) hebben. In dit geval is er dus een pprijs dus zou hij 1 rij moeten weergeven (de 2e in dit geval).

[engelbertus]

als je nu nog mer partners hebt die dat artikel hebben, en die dan verschillende kortingsprijzen hebben, krijg je dan niet nog meer ( dan 2 nu) rijen in je output?

en wat is daar dan eigenlijk fout aan?

edit:

oh.. je bedoelt kid=klant id en voor die kid is er natuurlijk maar 1 prijs in de prijslijst......

misschien de volgorde van de joins aanpassen?

[ Voor 29% gewijzigd door engelbertus op 10-07-2006 17:13 ]

[Verwijderd]

engelbertus schreef op maandag 10 juli 2006 @ 17:08:
als je nu nog mer partners hebt die dat artikel hebben, en die dan verschillende kortingsprijzen hebben, krijg je dan niet nog meer ( dan 2 nu) rijen in je output?

Nee, het is echt puur of het veld partnerartikelen.prijs is gezet of niet.

[moozzuzz]

Verwijderd schreef op maandag 10 juli 2006 @ 16:39:
Omdat meerdere partners dezelfde artikelen kunnen hebben...

OK, nu dan zal in de tabel van de parterartikelen, toch ook wel voorkomen voor welke partner dit is? Moet er dan niet ergens een

SQL:

WHERE partnerartikel.partnerid=partners.partnerid

voorkomen?

Of sorteren op pprijs en limit 0,1.

[ Voor 6% gewijzigd door moozzuzz op 10-07-2006 17:16 ]

[engelbertus]

doordat je
artikelen.prijs
EN
partnerartikelen.prijs AS pprijs
selecteert krijg je alleen als partnerartikelen.prijs bestaat een extra regel, naast de gewone regel met prijs.

je hebt dan dus twee "entrys" per klant gekregen. of is dit niet zo?

[ Voor 26% gewijzigd door engelbertus op 10-07-2006 17:23 ]

[PhysicsRules]

Deze output suggeert toch echt een dubbele record in partnerartikelen.

Wat krijg je voor output met partnerartikelen.aid = 13?

[engelbertus]

die joins zorgen er toch alleen voor dat als alle aangegeven ids kloppen er een regel wordt gemaakt?

dan kan het dus makkelijk dat er dus een regel bij komt voor arikelen.prijs EN partnerartikelen.prijs AS pprijs, indien partnerartikelen.prijs niet leeg is?
lijkt me logisch?

welk stukje sql voorkomt dan dat dit zou gebeuren?

[Verwijderd]

Bedankt! Door de antwoorden hierboven zag ik wat ik fout deed:

code:

                AND
                    partnerartikelen.pid = $partnerid

die had er nog bijgemoeten, want nu selecteerde hij inderdaad, zoals velen al suggereerde, meerdere rijen waarbij de rij dus soms toebehoorde aan een andere partner. Door samenloop van omstandigheden viel dit mij niet op.... stom...

Thanks iedereen voor het meedenken en de hulp!!!!