[MSSQL] Query met 7 result sets graag in 1

[Verwijderd]

Ik heb in MS SQL een tweetal tabellen voor een messageboard-module op ons intranet. Deze zijn:

svepweb_nieuwsgroepen
Deze tabel bevat de 7 boards die we op dit moment hebben met een ID en een naam.

svepweb_nieuwsgroepen_berichten
Je raadt het al, hier staan de berichten in met daarbij een boardId en de bericht tekst.

Nu wil ik in een stored procedure voor elk messageboard het meest recente bericht ophalen. (ben ik al 3 dagen mee bezig) en uiteindelijk ben ik via een cursor tot dit gekomen:

code:

DECLARE @au_id int
DECLARE @au_name varchar(50)
DECLARE @au_date datetime
DECLARE abc CURSOR FOR
SELECT * FROM svepweb_nieuwsgroepen

OPEN abc

FETCH NEXT FROM abc
INTO @au_id, @au_name

WHILE (@@FETCH_STATUS = 0)
BEGIN
   --- Get latest date for current board ---
   SELECT @au_date = MAX(datum) from svepweb_nieuwsgroepen_berichten WHERE boardId = @au_id

   --- Get latest post for current board ---
   SET ROWCOUNT 1
   SELECT boardId, onderwerp, datum from svepweb_nieuwsgroepen_berichten where boardId = @au_id AND datum = @au_date

   --- Go to next board ---
   FETCH NEXT FROM abc
   INTO @au_id, @au_name
END
CLOSE abc
DEALLOCATE abc

Dit werkt als een zonnetje, ik krijg 7 recordsets met daarin 1 record, namelijk dat record dat het meest recent is voor elk board.

Maar ik wil geen 7 queries vanuit ASP moeten doen om dat voor elk board op te moeten halen en ik krijg dus nu 7 recordsets terug. Met UNION kan ik weinig en ik heb ook met views lopen klooien maar ik zit helemaal vast. Heeft iemand een (waarschijnlijk veel handiger) manier om per messageboard het meest recente item terug te geven in 1 recordset? Mijn dank is groot.

[curry684]

Allereerst kun je dit met een temporary table en INSERT...SELECT constructie zo oplossen, maar waarom gebruik je in godesnaam een cursor?

[curry684]

Probeer dit eens:

SQL:

SELECT boardId, onderwerp, datum
FROM svepweb_nieuwsgroepen_berichten msg1
WHERE msg_id = (SELECT TOP 1 msg_id 
    FROM svepweb_nieuwsgroepen_berichten msg2
    WHERE msg1.boardId = msg2.boardId
    ORDER BY datum DESC);

En als het werkt, toon eens een query execution plan (Ctrl-L in Query Analyzer) want die ben ik wel benieuwd daar

[Verwijderd]

Precies wat ik zocht!

http://aella.ath.cx/Clipboard02.jpg

Dankjewel!!

[curry684]

Oei, wat hou ik toch van de optimizer van SQL Server, was beetje bang dat ie deze niet zo efficient zou wegkrijgen

Je indexen kloppen ook zo te zien en passant

[whoami]

2 table-scans.

* whoami zit zo met z'n cursor over die icoontjes te hooveren , en wacht maar tot de tooltips verschijnen.

[curry684]

whoami schreef op dinsdag 08 maart 2005 @ 16:12:
2 table-scans.

Nope ik checkte ook even, maar table scan is een ander icon Dit zijn clustered index scans

[whoami]

Idd, een table scan heeft zo een tabelletje ipv een 'tree'.

[Verwijderd]

Aangezien bij een clustered index het leaf-level de tabel zelf is, is een clustered-index scan gelijk aan een tablescan

[curry684]

Verwijderd schreef op dinsdag 08 maart 2005 @ 19:34:
Aangezien bij een clustered index het leaf-level de tabel zelf is, is een clustered-index scan gelijk aan een tablescan

Uhm volgens die logica is iedere index scan een table scan

Een table scan houdt in dat ieder record uitgelezen moet worden om te kunnen besluiten of deze relevant is voor de resultset, omdat op een veld gefilterd wordt dat niet geindexeerd is. In geval van een clustered index scan hoeven alleen de rows gericht gezocht te worden die voldoen aan de match, wat een extreem snelle scan is in tegenstelling tot de table scan. De nonclustered index scan is vergelijkbaar daaraan, maar minimaal verschillend omdat een losse index marginaal sneller doorzocht kan worden, en het ophalen van de record zelf vervolgens marginale extra performance kost.

In dit geval vinden er clustered index scans plaats oftewel die staan correct op het msg_id van de berichtentabel.

[whoami]

^^
met curry;
Bij een table scan moet de hele table overlopen worden, bij een clustered index scan moet slechts een gedeelte overlopen worden, nl. de rows die voldoen aan een gedeelte van de key.