|
|
 | MySQL: Begrænse per grupering
Fra : Kasper Johansen |
Dato : 14-12-05 12:52 |
|
Hej gruppe.
Jeg vil gerne have 5 billeder (bdk_galleri_pictures) fra hver gruppe
(bdk_galleri_groups), der bliver fundet via. følgende forspørgsel:
<query>
SELECT
bdk_galleri_pictures.nr,
bdk_galleri_pictures.pers,
bdk_galleri_pictures.groupid
FROM
bdk_galleri_groups,
bdk_galleri_spgroups_links,
bdk_galleri_pictures
WHERE
bdk_galleri_spgroups_links.spid = '$spgroupd[nr]' &&
bdk_galleri_groups.nr = bdk_galleri_spgroups_links.groupid &&
bdk_galleri_pictures.groupid = bdk_galleri_groups.nr
ORDER BY
bdk_galleri_pictures.nr
</query>
Da forspørgslen skal gentages mange gange, vil jeg gerne have lavet det hele
i en enkelt forspørgsel. Er det muligt? Og hvis ja, hvordan? Jeg bruger
MySQL 5.
--
Med venlig hilsen
Kasper Johansen
| |
 Michael Zedeler (14-12-2005)
| Kommentar
Fra : Michael Zedeler |
Dato : 14-12-05 18:45 |
|
Kasper Johansen wrote:
> Jeg vil gerne have 5 billeder (bdk_galleri_pictures) fra hver gruppe
> (bdk_galleri_groups), der bliver fundet via. følgende forspørgsel:
>
> <query>
> SELECT
> bdk_galleri_pictures.nr,
> bdk_galleri_pictures.pers,
> bdk_galleri_pictures.groupid
>
> FROM
> bdk_galleri_groups,
> bdk_galleri_spgroups_links,
> bdk_galleri_pictures
>
> WHERE
> bdk_galleri_spgroups_links.spid = '$spgroupd[nr]' &&
> bdk_galleri_groups.nr = bdk_galleri_spgroups_links.groupid &&
> bdk_galleri_pictures.groupid = bdk_galleri_groups.nr
Jeg tror ikke at && er standard SQL. Der skal vist stå AND. Jeg går ud
fra at mysql accepterer det, men alligevel...
> ORDER BY
> bdk_galleri_pictures.nr
> </query>
>
> Da forspørgslen skal gentages mange gange, vil jeg gerne have lavet det hele
> i en enkelt forspørgsel. Er det muligt? Og hvis ja, hvordan? Jeg bruger
> MySQL 5.
Jeg tror desværre ikke at du kan slippe udenom foreningsmængden af en
masse SELECT-forespørgsler. Altså
SELECT <gruppe 1> LIMIT 5
UNION
SELECT <gruppe 2> LIMIT 5
UNION
....
SELECT <gruppe n> LIMIT 5
Men noget helt andet er, at du har et dobbelt join i din forespørgsel.
Det er altså dyrt, så hvis du kører din forespørgsel ofte, kunne du
overveje at de-normalisere tabellerne en smule.
Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf
| |
Peter Brodersen (15-12-2005)
| Kommentar
Fra : Peter Brodersen |
Dato : 15-12-05 13:57 |
|
On Wed, 14 Dec 2005 18:44:47 +0100, Michael Zedeler
<michael@zedeler.dk> wrote:
>Jeg tror desværre ikke at du kan slippe udenom foreningsmængden af en
>masse SELECT-forespørgsler. Altså
Hvis antallet af forskellige grupper ikke er kendt, kan man benytte
sig af en subselect - fx:
http://lists.mysql.com/mysql/191825
>Men noget helt andet er, at du har et dobbelt join i din forespørgsel.
>Det er altså dyrt, så hvis du kører din forespørgsel ofte, kunne du
>overveje at de-normalisere tabellerne en smule.
Hvad tænker du på med at det er dyrt med det join? Det væsentlige er,
at der joines hen på keys, og mon ikke at der både er index på
bdk_galleri_groups.nr og bdk_galleri_pictures.groupid?
--
- Peter Brodersen
| |
 Michael Zedeler (15-12-2005)
| Kommentar
Fra : Michael Zedeler |
Dato : 15-12-05 14:56 |
|
Peter Brodersen wrote:
> On Wed, 14 Dec 2005 18:44:47 +0100, Michael Zedeler
> <michael@zedeler.dk> wrote:
>
>>Jeg tror desværre ikke at du kan slippe udenom foreningsmængden af en
>>masse SELECT-forespørgsler. Altså
>
> Hvis antallet af forskellige grupper ikke er kendt, kan man benytte
> sig af en subselect - fx:
> http://lists.mysql.com/mysql/191825
Det er en smart løsning, men hvordan performer den? I teorien skalerer
tiden som o(x^2), hvor x er antallet af rækker, så hvis man har mange
rækker, bliver den pænt dyr.
>>Men noget helt andet er, at du har et dobbelt join i din forespørgsel.
>>Det er altså dyrt, så hvis du kører din forespørgsel ofte, kunne du
>>overveje at de-normalisere tabellerne en smule.
>
> Hvad tænker du på med at det er dyrt med det join? Det væsentlige er,
> at der joines hen på keys, og mon ikke at der både er index på
> bdk_galleri_groups.nr og bdk_galleri_pictures.groupid?
Selv med indexes, koster det jo en del ekstra at lave joins, frem for
ikke at gøre det. Specielt hvis databasen laver meget andet, så den når
at smide det ud af cachen før hver forespørgsel.
Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf
| |
Peter Brodersen (15-12-2005)
| Kommentar
Fra : Peter Brodersen |
Dato : 15-12-05 15:27 |
|
On Thu, 15 Dec 2005 14:56:12 +0100, Michael Zedeler
<michael@zedeler.dk> wrote:
>> Hvis antallet af forskellige grupper ikke er kendt, kan man benytte
>> sig af en subselect - fx:
>> http://lists.mysql.com/mysql/191825
>Det er en smart løsning, men hvordan performer den? I teorien skalerer
>tiden som o(x^2), hvor x er antallet af rækker, så hvis man har mange
>rækker, bliver den pænt dyr.
Sandsynligvis skalerer den ikke vildt fantastisk, men hvis ens
datamængde ikke er vanvittig, kan det være en nødvendighed som
alternativ til at fedte med det manuelt.
>> Hvad tænker du på med at det er dyrt med det join? Det væsentlige er,
>> at der joines hen på keys, og mon ikke at der både er index på
>> bdk_galleri_groups.nr og bdk_galleri_pictures.groupid?
>Selv med indexes, koster det jo en del ekstra at lave joins, frem for
>ikke at gøre det. Specielt hvis databasen laver meget andet, så den når
>at smide det ud af cachen før hver forespørgsel.
Et direkte index-opslag er altså hysterisk hurtigt, og det plejer ikke
at være dér, den umiddelbare optimering finder sted. En langt større
ulempe kan være, hvis én af tabellerne opdateres temmeligt ofte pga.
MyISAMs table locks, men samme problemstilling finder man også ved en
de-normalisering.
Idet et galleri nok oftere bliver hentet end ændret, vil MySQLs
querycache sandsynligvis alligevel kunne tage sig af langt de fleste
bekymringer.
--
- Peter Brodersen
| |
Thorbjørn Ravn Ander~ (15-12-2005)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 15-12-05 15:34 |
|
Michael Zedeler <michael@zedeler.dk> writes:
> Det er en smart løsning, men hvordan performer den? I teorien skalerer
> tiden som o(x^2), hvor x er antallet af rækker, så hvis man har mange
> rækker, bliver den pænt dyr.
Det afhænger jo af hvor kvik databasen er. Jeg mener fx at Oracle kan
genkende sådanne, og lave passende indekser over subselectresultatet.
> Selv med indexes, koster det jo en del ekstra at lave joins, frem for
> ikke at gøre det. Specielt hvis databasen laver meget andet, så den
> når at smide det ud af cachen før hver forespørgsel.
Det lyder som noget man kunne overveje at måle på. Understøtter MySQL
efterhånden noget i stil med "EXPLAIN PLAN"?
--
Thorbjørn Ravn Andersen
| |
Kasper Johansen (21-12-2005)
| Kommentar
Fra : Kasper Johansen |
Dato : 21-12-05 13:52 |
|
Michael Zedeler skrev:
> Det er en smart løsning, men hvordan performer den?
Der er 252 indlæg i "bdk_comments_comments", 278 i "bdk_comments", 4
indlæg i "bdk_users_blogs". Så det er ikke det store.
Den har ingen problemer overhovedet med performance overhovedet.
Set i forhold til de andre scripts der bliver kørt, vil jeg gætte på
0,001 sek. for lige den forspørgsel.
Jeg takker for alle svar, og skriver scriptet om :)
--
Med venlig hilsen
Kasper Johansen
| |
|
|