SQL probleem

[Morpheus_at_work]

ik heb 3 tabellen

tabel : FPreactie_systeem


daaronder hangen een aantal item die ik weer wil geven

FPreactieDate datum van de reactie
FPreactieParameter afhankelijk van of het een reactie is op een nieuwsitem is het N of Review een R
FPreactieItemID id van het idem waarop het een reactie is


Tabel : Nieuws

NieuwsID id van het nieuwsitem
NieuwsTitel titel van nieuws
NieuwsParameter nieuwsparameter (N)

Tabel : Review

ReviewID id van reviewitem
ReviewTitel titel van review
ReviewParameter reviewparameter (R)


wat ik nu wil geven is een top 15 van reacties op nieuws en review gesorteerd op FPreactieDate ,

hij moet dus een join leggen tussen NieuwsID en FPreactieItemID en NieuwsParameter en FPreactieParameter en om ook review erbij te pakken ReviewID en FPreactieItemID en ReviewParameter en FPreactieParameter


ik heb al verscheidene dingen geprobeerd maar het leidde niet tot succes

wat ik als resultaat wil hebben is FPreactieDate , FPreactieParameter , FPreactieItemID , NieuwsTitel as Titel of ReviewTitel as Titel

al vast bedankt voor het mee willen denken

[Verwijderd]

Wat heb je zoal geprobeerd ?

Dan kunnen we daar reacties opgeven

[cameodski]

Lukt het wel als je alleen een Nieuws of Review tabel zou hebben, gecombineerd met FPreactie_systeem?
En alleen met de tabel FPreactie_systeem?

[Morpheus_at_work]

het gaat goed zolang ik maar alleen of nieuws of alleen review combineer met fpreactie_systeem

[cameodski]

Post die query eens. Als je M%SQL gebruikt, kun je gebruik maken van LEFT JOIN. Vervolgens afhankelijk van FPreactieParameter de waarde uit Nieuws of Review pakken.

[Morpheus_at_work]

maar hij geeft 0 resultaten terug als ik ze beide koppel

code:

SELECT FPreactie_systeem.FPreactieID, FPreactie_systeem.FPreactieDate, 

FPreactie_systeem.FPreactieParameter, Nieuws.NieuwsTitle,  Review.ReviewTitel

FROM Review INNER JOIN (Nieuws INNER JOIN FPreactie_systeem ON 

(Nieuws.NieuwsParameter = FPreactie_systeem.FPreactieParameter) AND 

(Nieuws.NieuwsID = FPreactie_systeem.FPreactieItem)) ON 

(Review.ReviewParameter = FPreactie_systeem.FPreactieParameter) AND 

(Review.ReviewID = FPreactie_systeem.FPreactieItem)

[cameodski]

OK, je krijgt ongeveer zoiets:

code:

SELECT FP.*, R.ReviewTitel, N.NieuwsTitel
FROM FPreactie_systeem FP
LEFT JOIN Review R ON R.ReviewID = FP.FPreactieItemID
LEFT JOIN Nieuws N ON N.NieuwsID = FP.FPreactieItemID

Hoe je het geheel terug kunt krijgen in één titel veld, hangt af van het RDBMS.

[Morpheus_at_work]

code:

SELECT FPreactie_systeem.FPreactieID, FPreactie_systeem.FPreactieDate, 

FPreactie_systeem.FPreactieParameter, Nieuws.NieuwsTitle,  Review.ReviewTitel

FROM Review RIGHT  JOIN (Nieuws RIGHT JOIN FPreactie_systeem ON 

(Nieuws.NieuwsParameter = FPreactie_systeem.FPreactieParameter) AND (Nieuws.NieuwsID 

= FPreactie_systeem.FPreactieItem)) ON (Review.ReviewParameter = 

FPreactie_systeem.FPreactieParameter) AND (Review.ReviewID = 

FPreactie_systeem.FPreactieItem)

dit werkt nu door die right joins , helaas werkt het niet om of nieuwtitel of reviewtitel weer te gegeven ik krijg ze nu beide , 1 is leeg of de ander is gevuld , beide een as Titel aangeven mag niet

[Morpheus_at_work]

cameodski schreef op 21 oktober 2002 @ 20:17:
OK, je krijgt ongeveer zoiets:

code:

SELECT FP.*, R.ReviewTitel, N.NieuwsTitel
FROM FPreactie_systeem FP
LEFT JOIN Review R ON R.ReviewID = FP.FPreactieItemID
LEFT JOIN Nieuws N ON N.NieuwsID = FP.FPreactieItemID

Hoe je het geheel terug kunt krijgen in één titel veld, hangt af van het RDBMS.

maak het nu in access , maar gaat sql server worden

[Mart!]

Je moet een UNION gebruiken om resultaten 'onder elkaar te plakken', dus:

code:

SELECT FP.*, R.ReviewTitel AS Titel
FROM FPreactie_systeem FP
LEFT JOIN Review R ON R.ReviewID = FP.FPreactieItemID
UNION
SELECT FP.*, N.NieuwsTitel AS Titel
FROM FPreactie_systeem FP
LEFT JOIN Nieuws N ON N.NieuwsID = FP.FPreactieItemID

Met een join had je dat nooit voor elkaar gekregen en daarom hebben ze de UNION operation uitgevonden

Zie ook http://www.devguru.com/Te...etsql/quickref/union.html - Google levert ook veel info over het gebruik van UNION

Voor de leek:
JOIN: resultaten in kolommen naast elkaar
UNION: resultaten in rijen onder elkaar

[cameodski]

Morpheus_at_work schreef op 21 oktober 2002 @ 20:19:
maak het nu in access , maar gaat sql server worden

In Access kun je volgens mij de IIF functie gebruiken.
In SQL Server moet je in ieder geval CASE gebruiken.

[cameodski]

Mart! schreef op 21 oktober 2002 @ 20:52:
Met een join had je dat nooit voor elkaar gekregen en daarom hebben ze de UNION operation uitgevonden

Oh jawel hoor, met een join lukt dat uitstekend.

Zie ook http://www.devguru.com/Te...etsql/quickref/union.html - Google levert ook veel info over het gebruik van UNION

UNION kan inderdaad ook, maar dan moet je je LEFT JOIN's wel vervangen door gewone JOIN's en in beide select-statements filteren op FPreactieParameter.

[Morpheus_at_work]

cameodski schreef op 21 oktober 2002 @ 23:36:
[...]

Oh jawel hoor, met een join lukt dat uitstekend.

[...]

UNION kan inderdaad ook, maar dan moet je je LEFT JOIN's wel vervangen door gewone JOIN's en in beide select-statements filteren op FPreactieParameter.

denk dat een union qua performance velen malen slechter is dan een join

[Janoz]

Het lijkt me makkelijker om reviews en nieuws in 1 tabel te zetten en hier vervolgens een typoe veld in te zetten wat nieuws en wat een review is. Zoals ik het nu zie is er vanuit db oogpunt weinig verschil tussen nieuws en review.

[FastWallie]

Janoz schreef op 22 oktober 2002 @ 11:51:
Het lijkt me makkelijker om reviews en nieuws in 1 tabel te zetten en hier vervolgens een typoe veld in te zetten wat nieuws en wat een review is. Zoals ik het nu zie is er vanuit db oogpunt weinig verschil tussen nieuws en review.

Zo dacht ik er net over. Dit is vele malen beter voor de performance. Unions zijn niet leuk voor de perf.

[cameodski]

De tabellen Nieuws en Review lijken inderdaad veel op elkaar. Op basis van deze ene query lijkt het verstandig te zijn om ze in één tabel te zetten.
Wij weten alleen niet welke queries er verder nog zijn. Tis een beetje koffiedik kijken.

[Janoz]

cameodski schreef op 22 oktober 2002 @ 13:22:
De tabellen Nieuws en Review lijken inderdaad veel op elkaar. Op basis van deze ene query lijkt het verstandig te zijn om ze in één tabel te zetten.
Wij weten alleen niet welke queries er verder nog zijn. Tis een beetje koffiedik kijken.

Ik baseer het niet op die ene query, maar op het db-ontwerp. Nieuws en review lijken nu zo erg op elkaar qua functionaliteit dat het onzin is om ze juist in verschillende tabellen neer te zetten. Vanuit het menselijk oogpunt is het misschien wel logisch, maar je moet er juist vanuit het db oogpunt naar kijken. Alle andere queries zijn waarschijnlijk simpel aan te passen door een where type=review oid toe te voegen.

Daarnaast is het flexibeler. Stel, je wilt ook artikelen toevoegen. Een extra type is genoeg. Je hele reactie structuur werkt automatisch al.

[cameodski]

Janoz schreef op 22 oktober 2002 @ 14:12:
Ik baseer het niet op die ene query, maar op het db-ontwerp. Nieuws en review lijken nu zo erg op elkaar qua functionaliteit dat het onzin is om ze juist in verschillende tabellen neer te zetten. Vanuit het menselijk oogpunt is het misschien wel logisch, maar je moet er juist vanuit het db oogpunt naar kijken. Alle andere queries zijn waarschijnlijk simpel aan te passen door een where type=review oid toe te voegen.

Daarnaast is het flexibeler. Stel, je wilt ook artikelen toevoegen. Een extra type is genoeg. Je hele reactie structuur werkt automatisch al.

Ik denk dat je gelijk hebt, maar het hoeft niet noodzakelijkerwijs.
Security zou bijvoorbeeld een reden kunnen zijn. En bij veel queries zul je inderdaad een extra filter op type nodig hebben.

Als je alleen naar de gegegeven db-structuur en query kijkt, lijkt dit inderdaad onwaarschijnlijk, maar een enkele nuance kan geen kwaad.

[Crazy D]

cameodski schreef op 22 oktober 2002 @ 14:22:
Ik denk dat je gelijk hebt, maar het hoeft niet noodzakelijkerwijs.
Security zou bijvoorbeeld een reden kunnen zijn.

Hoe bedoel je dat? Wat zou dan een security risico kunnen zijn? (ik bedoel, als je nieuws.php aanroept, doe je in code ipv select * from tNews, select * from tDinges where type=1, en bij reviews.php type=2 in je query. Daar zie ik geen verschil tussen, dus ik vraag me af wat voor security risico eraan zou zitten. Je moet natuurlijk wel in code afvangen dat iemand die alleen nieuws mag posten, geen reviews neerdumpt, maar ja, dat soort dingen moet je sowieso al afvangen.).

[Morpheus_at_work]

Janoz schreef op 22 oktober 2002 @ 11:51:
Het lijkt me makkelijker om reviews en nieuws in 1 tabel te zetten en hier vervolgens een typoe veld in te zetten wat nieuws en wat een review is. Zoals ik het nu zie is er vanuit db oogpunt weinig verschil tussen nieuws en review.

Klopt want heb niet alles laten zien

vanwege normalisering heb ik nieuws en reviews gescheiden , omdat nieuws andere kenmerken heeft dan een review , zo heeft een review chapters , anders had ik database table met gigantisch veel lege velden en dat is niet netjes althans dat vind ik.

[cameodski]

Crazy_D schreef op 22 oktober 2002 @ 16:13:
Hoe bedoel je dat? Wat zou dan een security risico kunnen zijn? (ik bedoel, als je nieuws.php aanroept, doe je in code ipv select * from tNews, select * from tDinges where type=1, en bij reviews.php type=2 in je query. Daar zie ik geen verschil tussen, dus ik vraag me af wat voor security risico eraan zou zitten. Je moet natuurlijk wel in code afvangen dat iemand die alleen nieuws mag posten, geen reviews neerdumpt, maar ja, dat soort dingen moet je sowieso al afvangen.).

Waarom denk je dat je in SQL Server oa op tabellen afzonderlijk de rechten in kunt stellen?
Je zult mij niet horen zeggen dat er sprake is van een gebrek aan security, maar er het is gewoon een extra zekerheid.

[Crazy D]

cameodski schreef op 22 oktober 2002 @ 17:05:
Waarom denk je dat je in SQL Server oa op tabellen afzonderlijk de rechten in kunt stellen?
Je zult mij niet horen zeggen dat er sprake is van een gebrek aan security, maar er het is gewoon een extra zekerheid.

Ja maar dat heeft dan alleen maar zin als je met sql-users werkt, en dit zal een vaste sql-login zijn die je gebruikt, net als hier (tenzij ie alle admins en zo ook een eigen sql-login geeft ).

(maar tis op zich idd wel iets wat je in t achterhoofd kunt houden, dat ben ik wel met je eens)

[cameodski]

Crazy_D schreef op 22 oktober 2002 @ 17:22:
Ja maar dat heeft dan alleen maar zin als je met sql-users werkt, en dit zal een vaste sql-login zijn die je gebruikt, net als hier (tenzij ie alle admins en zo ook een eigen sql-login geeft ).

(maar tis op zich idd wel iets wat je in t achterhoofd kunt houden, dat ben ik wel met je eens)

Agree.

[Annie]

FastWallie schreef op 22 oktober 2002 @ 13:08:
[...]
Zo dacht ik er net over. Dit is vele malen beter voor de performance. Unions zijn niet leuk voor de perf.

Mijn eerste ingeving zou juist zijn dat een union van losse ("simpele") queries juist sneller door de database verwerkt worden dan een ("ingewikkeldere") join.

Heb je misschien documentatie die mij kan overtuigen van mijn ongelijk?

[cameodski]

Annie schreef op 23 oktober 2002 @ 01:52:
Mijn eerste ingeving zou juist zijn dat een union van losse ("simpele") queries juist sneller door de database verwerkt worden dan een ("ingewikkeldere") join.

Het RDBMS moet natuurlijk wel twee queries uitvoeren en bij een normale UNION wordt ook nog eens een DISTINCT toegepast (in MSSQL tenminste).
Maar het hangt natuurlijk helemaal af van de optimizer. En je kunt vaak wel beredeneren wat ie ongeveer gaat doen, maar dat o.a. weer af van de aanwezige indexen ed.

[Annie]

cameodski schreef op 23 oktober 2002 @ 09:57:
[...]

Het RDBMS moet natuurlijk wel twee queries uitvoeren en bij een normale UNION wordt ook nog eens een DISTINCT toegepast (in MSSQL tenminste).

Oke, die DISTINCT was ik effe vergeten (maken we er snel een UNION ALL van ).

Om op de rest terug te komen. Het ging mij om het verschil tussen een UNION en een JOIN. En wat zie je als het uitvoeren van 1, 2, ..., n queries door de DB? imho worden bij een JOIN ook meerdere queries uitgevoerd.

cameodski schreef op 23 oktober 2002 @ 09:57:
En je kunt vaak wel beredeneren wat ie ongeveer gaat doen, maar...

Daarom zei ik ook: "Mijn eerste ingeving...", maar wilde eigenlijk wel wat bewijs zien. Misschien toch maar 's wat testjes gaan doen.