[SQL] Probleem met query

[Verwijderd]

Ik heb een probleem met een database query of een access database, zo ziet me database eruit:

adfTopics:
- TopicsId (PK)
- ForumId
- LastReply

adfThreads
- PostId (PK)
- TopicId
- MemberId
- Subject
- PostDateTime

adfPermissions
- ForumId (PK)
- GroupId (PK)
- AllowRead

Nu wil ik de laatste 15 topics selecteren met het subject daarbij
van alle members die in de groep zitten met als GroupId 1

Zelf had ik deze query bedacht:

code:

SELECT TOP 15 adfTopics.TopicId, adfThreads.Subject
FROM adfTopics, adfThreads, adfPermissions
WHERE adfThreads.PostId IN (SELECT MIN(PostId) FROM adfThreads GROUP BY TopicId)
AND adfThreads.TopicId = adfTopics.TopicId
AND adfPermissions.ForumId = adfTopics.ForumId
AND adfPermissions.GroupId = 1
AND adfPermissions.AllowRead = True
ORDER BY adfTopics.LastReply DESC , adfThreads.PostDateTime

Maar dat is veelste langzaam soms duurd het meer dat 1 seconden om deze query uit te voeren

[BtM909]

Over hoeveel records praten we zonder die limit?

[whoami]

Heb je indexen liggen op de velden waarop je joined / zoekt ?
Ik vraag me ook af wat die subquery daar doet.

[ Voor 29% gewijzigd door whoami op 08-03-2005 12:08 ]

[semicon]

Het gaat om ongeveer 2500 records.

( het forum werkt nu verder supersnel op access :x )

[ Voor 46% gewijzigd door semicon op 08-03-2005 12:28 ]

[jwpmzijl]

Je gebruikt een access database voor een forum op een website??
Beschrijf eens op welke wijze je de connectie tussen de database en jouw website maakt en vanuit welke taal je de tabellen benadert. Jet tabellen staan nou niet bekend om hun snelheid in een webomgeving

Als je met Access/Jet tabellen werkt is het wellicht beter om te werken met joins dat zou al een performance winst kunnen opleveren. En zoals WHOAMI ook al aangeeft zorg dat er indexen aanwezig zijn op alle velden die je in de joins gebruikt.

SELECT TOP 15 *
FROM [tabel1] LEFT JOIN [tabel2] ON [tabel1].ID = [Tabel2].ID
WHERE.............;

[Verwijderd]

whoami schreef op dinsdag 08 maart 2005 @ 12:07:
Heb je indexen liggen op de velden waarop je joined / zoekt ?
Ik vraag me ook af wat die subquery daar doet.

Met die query kan ik de eerste post in de topic zien waarvan ik de subject nodig heb...

indexen enzo zitten goed, het grootste probleem is eigelijk de subject daarvoor moet je de eerste post in een topic te pakken zien te krijgen. Volgens mij maakt die subquery de query zo langzaam.

Maar ik heb geen idee hoe ik het anders zou kunnen doen, iemand?

[ Voor 7% gewijzigd door Verwijderd op 08-03-2005 12:45 ]

[whoami]

Die subquery maakt je query idd langzam.
Ik blijf me echter wel afvragen waarom je die nodig hebt, als je gewoon de subjects wilt ophalen.

[Verwijderd]

Ja ik kan het een beetje moeilijk verwoorden... zal nog een keer proberen .

Ik heb die subquery nodig omdat in de adfThreads tabel alle berichten staan van de topics (dus ook de 1e post) Ik heb het subject van de topic nodig dat dus de eerste post is van een bepaalde topic in de adfThreads tabel. Die subquery was het enige wat ik kon bedenken om die eerste post te krijgen.

[kasper_vk]

Waarom sla je het subject dan niet per topic op (dus in je topics-tabel) ?

[ Voor 3% gewijzigd door kasper_vk op 08-03-2005 13:02 ]

[whoami]

kasper_vk schreef op dinsdag 08 maart 2005 @ 13:02:
Waarom sla je het subject dan niet per topic op (dus in je topics-tabel) ?

Idd, want het subject heeft niets te maken met een post, maar wel met het 'topic'.
En wat staat er in 'subject' bij de andere posts (die geen topicstart zijn) ?

[bigbeng]

Een aantal vraagjes:

1) Volgens mij mis ik een tekstveld in je datamodel waar mensen hun forumpost in schrijven. Heb je dit moedwillig achterwege gelaten, of zit dit in een andere tabel?

2) Kunnen mensen de subject aanpassen als ze een reply doen? Zo nee, is deze dan leeg, of staat hier hetzelfde in als in de hoofdpost? Indien dat eerste, dan kun je ook in je where opnemen dat de subject niet leeg mag zijn. Indien mensen wel het subject kunnen aanpassen, misschien moet je dan een threadstart en een reply in aparte tabellen gaan stoppen, of eventeel middels een extra veld (bv threadstart YES/NO) het onderscheid maken tussen de eerste post en alle andere.

[P_de_B]

Uit m'n hoofd, maar volgens mij iets als onderstaande moeten werken:

code:

SELECT TOP 15 adfTopics.TopicId , adfThreads.Subject ,adfThreads.PostId
FROM adfTopics
INNER JOIN adfThreads ON adfTopics.TopicId = adfThreads.TopicId
INNER JOIN adfPermissions ON adfTopics.ForumId = adfPermissions.ForumId
INNER JOIN adfThreads t2 ON adfTopics.TopicId = t2.TopicId
WHERE adfPermissions.GroupId = 1
    AND adfPermissions.AllowRead = TRUE
GROUP BY adfTopics.TopicId , adfThreads.Subject ,adfThreads.PostId
ORDER BY adfTopics.LastReply DESC, adfThreads.PostDateTime
HAVING MIN(t2.PostId) = adfThreads.PostId

[Verwijderd]

whoami schreef op dinsdag 08 maart 2005 @ 13:08:
[...]
Idd, want het subject heeft niets te maken met een post, maar wel met het 'topic'.
En wat staat er in 'subject' bij de andere posts (die geen topicstart zijn) ?

Je kan (net zoals bij phpbb) ook een subject geven voor een reply.

bigbeng schreef op dinsdag 08 maart 2005 @ 13:12:
Een aantal vraagjes:

1) Volgens mij mis ik een tekstveld in je datamodel waar mensen hun forumpost in schrijven. Heb je dit moedwillig achterwege gelaten, of zit dit in een andere tabel?

2) Kunnen mensen de subject aanpassen als ze een reply doen? Zo nee, is deze dan leeg, of staat hier hetzelfde in als in de hoofdpost? Indien dat eerste, dan kun je ook in je where opnemen dat de subject niet leeg mag zijn. Indien mensen wel het subject kunnen aanpassen, misschien moet je dan een threadstart en een reply in aparte tabellen gaan stoppen, of eventeel middels een extra veld (bv threadstart YES/NO) het onderscheid maken tussen de eerste post en alle andere.

1) Heb ik achterwegen gelaten, dacht niet dat het relevant zou zijn voor deze query
2) Ja je kan subject opgeven als je reply geeft, mischien is een extra veld een idee maar ik hoop toch dat er een andere oplossing is.

Alles werkt al perfect (zie http://tweakweb.nl/forum) op dit na...

[bigbeng]

Wat nog wel eens wil helpen met een slome subquery is het opnemen van voorwaarden uit de buitenste query in de binnenste query. Dus:

code:

SELECT TOP 15 adfTopics.TopicId, adfThreads.Subject
FROM adfTopics, adfThreads th1, adfPermissions
WHERE th1.PostId IN (SELECT MIN(PostId) FROM adfThreads th2 WHERE th2.topicid=th1.topicid)
AND adfThreads.TopicId = adfTopics.TopicId
AND adfPermissions.ForumId = adfTopics.ForumId
AND adfPermissions.GroupId = 1
AND adfPermissions.AllowRead = True
ORDER BY adfTopics.LastReply DESC , adfThreads.PostDateTime

Dat kan zo weer een full tablescan schelen

[Verwijderd]

Nog steeds te langzaam, het is nu tijdelijk opgelost door middel 2 queries te gebruiken. Ik denk toch dat ik maar een extra veld ga toevoegen in de database, ben wel is vaker tegen dit probleem aangelopen en heb het toen ook opgelost op een 'prutserige' manier

Bedank voor jullie hulp

[P_de_B]

Heb je mijn oplossing, zonder subquery, geprobeerd? Ik zou gokken dat dat sneller gaat

[Verwijderd]

geprobeerd maar is denk ik iets te ingewikkeld voor access, hij werkte niet

[Verwijderd]

Verwijderd schreef op dinsdag 08 maart 2005 @ 17:01:
geprobeerd maar is denk ik iets te ingewikkeld voor access, hij werkte niet

Komt dat niet doordat de ORDER BY in zijn voorbeeld tussen de GROUP BY en HAVING in staat? Met zo'n constructie heb ik altijd geleerd GROUP BY .... HAVING .... ORDER BY ....

Ik moet toegeven dat ik de SQL specificatie er niet op nagezocht heb, maar volgens mij mag je ORDER BY niet tussen een GROUP BY en een HAVING in staan. Misschien heeft Access er daarom problemen mee?