sql-statement sneller maken??

[anoniem]

Ik ben voor een project het volgende sql statement aan het uitvoeren: SELECT wals.walscode, wals.lasdiam, wals.uitgangsdiam, wals.setcode, (SELECT max(bewerkingsdatum) FROM walsbewerking WHERE walsbewerking.walscode = wals.walscode AND walsbewerking.lasdiam = wals.lasdiam AND walsbewerking.uitgangsdiam = wals.uitgangsdiam AND walsbewerking.setcode = wals.setcode) FROM wals ORDER BY wals.walscode, wals.lasdiam, wals.uitgangsdiam, wals.setcode (walscode, uitgangsdiam, lasdiam en setcode zijn de sleutelvelden) als ik dit statement laat lopen heeft het ruim een halve minuut nodig tot een antwoord(output) te komen, dit is natuurlijk erg lang! kan iemand mij vertellen hoe ik dat zou kunnen omzetten naar een JOIN statement, watn dit schijnt sneller te zijn......ik weet alleen niet hoe ik dat moet doen. alvast bedankt alain dacier

[anoniem]

Ben je twee tabellen met elkaar aan het vergelijken of zo? En dan de vraag: wat wil je joinen?

[anoniem]

bij elk record in de 'wals' tabel wil ik dmv de 4 sleutelvelden(walscode, lasdiam, uitgangsdiam, setcode) de bewerkingsdatum ophalen in de 'walsbewerking' tabel. MAAR er zijn voor elk record in de wals tabel meerdere records uit de walsbewerking tabel (meerdere bewerkingsdatums). nu wil ik voor elk record uit de wals tabel de laatste datum uit de walsbewerking tabel. en WAT wil ik joinen: de 4 sleutelwaarde. maar met bovenstaande sqlstatement duurt dit dus ruim een halve minuut....en ik hoop dat het met een join sneller kan

[anoniem]

Ik denk dat er iets helemaal fout zit in je tabellen. Heb je wel eens van redundantie of normaliseren gehoord? En vier joins tussen twee tabellen lijkt me helemaal een foute boel. Kun je een screenshot van je tabellen maken?

[anoniem]

screenshot mag niet ivm informatie die ik niet mag vrijgeven. en ja, ik weet wel wat redundantie en normaliseren is en ik weet ook dat de tabellen eingelijk anders hadden gemoeten, maar hetgeen ik nu aant maken ben is iets wat in eerste instantie niet had gehoeven. later werd beslist om het toch maar even te maken en nu moet ik t dus oplossen...... maar ook met de huidige indeling is het te realiseren, toch?

[anoniem]

Lijkt me niet nee. [quote:f7299c2df2]ORDER BY wals.walscode, wals.lasdiam, wals.uitgangsdiam, wals.setcode [/quote:f7299c2df2] Als je nou eens begon met op slechts één veld te sorteren, dat scheelt een hele hap in snelheid.

[anoniem]

complete ORDER BY weggehaald, besparing: 0,5 sec. dus hier moeten we het antwoord niet zoeken denk ik

[anoniem]

Kijk je probleem zit hem in het feit dat je [u:6a207d855f]twee[/u:6a207d855f] tabellen op [u:6a207d855f]vier [/u:6a207d855f]manieren (lees: velden) met elkaar wilt [u:6a207d855f]koppelen[/u:6a207d855f]. Daar klopt niets van. Of begrijp ik je verkeerd en wil je het op slechts een veld koppelen? Dan zou ik zeggen: google, het Internet sterft van de voorbeelden.

[anoniem]

nee, ik moet de tabellen op 4 velden koppelen, want die 4 velden zijn voor beide tabellen de samengestelde sleutel

[anoniem]

Dan hoef je alleen beide sleutels te vergelijken lijkt mij.

[anoniem]

en hoe kom ik dan aan de bewerkingsdatum dmv een join statement?

[anoniem]

Ik heb zelf nog nooit een select-statement met twee 'selects' erin gemaakt dus ik kan het je niet vertellen. Maar de tip is altijd: [i:e1da02a8d9]bouw je sql stukje bij beetje op.[/i:e1da02a8d9] Annie neemt het straks wel over :D

[anoniem]

met een beetje hulp van verschillende mensen is het zo geregeld, dit is het antwoord op mijn vraag: SELECT wals.walscode, wals.lasdiam, wals.uitgangsdiam, wals.setcode, max(walsbewerking.bewerkingsdatum) FROM wals LEFT JOIN walsbewerking ON (wals.walscode = walsbewerking.walscode AND wals.lasdiam = walsbewerking.lasdiam AND wals.uitgangsdiam = walsbewerking.uitgangsdiam AND wals.setcode = walsbewerking.setcode) GROUP BY wals.walscode, wals.lasdiam, wals.uitgangsdiam, wals.setcode alain

[anoniem]

Dat is dus EEN Join en niet vier. De rest zijn vergelijkingen. (volgens mij) Ik heb je dus verkeerd begrepen.

[anoniem]

ohzo, ja 1 join, maar op 4 velden. ja dat verschil was me voor nu ook niet duidelijk.... toch bedankt voor de hulp alain

[anoniem]

ohzo, ja 1 join, maar op 4 velden. ja dat verschil was me voor nu ook niet duidelijk.... toch bedankt voor de hulp alain

[anoniem]

Tot je dienst :D

[anoniem]

Weet je ook waarom je query zo traag was? Indien niet, of voor andere bezoekers die het graag willen weten: de query bevatte een zogenaamde correlated subquery. En die zijn over het algemeen funest voor je performance. Voor elk resultaat wordt een table/index-scan uitgevoerd. Gelukkig zijn ze in veel gevallen (weet niet of het in alle gevallen mogelijk is) redelijk eenvoudig om te schrijven naar een join. Als je met MS SQL Server werkt, dan kan je in de Query Analyzer het execution plan laten genereren. Dat geeft vaak al goede inzichten in de 'pijnpunten' van een query. Overigens bevat je query nu een outer-join. Als je alleen de laatste bewerkingsdata wil hebben voor een [i:651348509c]wals[/i:651348509c], dan betekent dat dus dat er voor je resultaat altijd een [i:651348509c]walsbewerking[/i:651348509c] moet zijn. In dat geval kan je dus ook een (inner) join gebruiken; en die zijn weer net wat sneller dan een outer-join (alhoewel het verschil natuurlijk niet zo drastisch zal zijn als na het verwijderen van de subquery). [size=9:651348509c]btw. Wiep, ik kom niet zo vaak in dit forum. Dus wachten op mij is een beetje zinloos ;) (maar eigenlijk geldt dat ook voor de fora waar ik wel vaak zit).[/size:651348509c]

[anoniem]

Als ik even mag gokken levert de analyze met query analyzer op dat de vergelijkingen in de eerste query leiden tot full table scans en in de join manier niet. Waarschijnlijk interpreteert de query optimizer dit laatste beter. Uit nieuwscierigheid: Hoeveel records staan er in de tabellen en hoeveel winst heb je behaald? Grtz,

[anoniem]

[quote:f52d693e0f="beheer25"]Als ik even mag gokken levert de analyze met query analyzer op dat de vergelijkingen in de eerste query leiden tot full table scans en in de join manier niet. Waarschijnlijk interpreteert de query optimizer dit laatste beter. [/quote:f52d693e0f] Heb je ook mijn antwoord gelezen? Het probleem is de correlated subquery. Overigens zal de query met de outer join ook altijd een table scan (of index scan) opleveren. Maar dat is lang niet zo funest als een scan (of desnoods een index seek) voor elk gevonden resultaat in de 'buiten-query' van de eerste query.