Kristian Damm Jensen wrote:
> Michael Zedeler wrote:
>> Kristian Damm Jensen wrote:
>>> Michael Zedeler wrote:
>>>> Leif Neland wrote:
>>>>> Gert Krabsen wrote:
>>>>>> Jeg har en tabel, der (meget forenklet) ser sådan ud:
>>>>>>
>>>>>> Navn Nummer
>>>>>> Peter 5
>>>>>> Jens 5
>>>>>> Peter 6
>>>>>> Peter 12
>>>>>> Anders 4
>>>>>> Jens 6
>>>>>>
>>>>>> Men hvis jeg gerne vil have alle navne, der har _alle_ tre numre 5
>>>>>> ,6, 12 (I dette tilfælde er resultatet Peter
>>>>>>
>>>>>> ..hvordan gør jeg lettest det???
>>>>> Man kunne også lave
>>>>> select a.navn from tbl a
>>>>> inner join tbl b using (navn)
>>>>> inner join tbl c using(navn)
>>>>> where a.nummer=5
>>>>> and b.nummer=6
>>>>> and c.nummer=12
>>>>>
>>>>> Men om det er mere eller mindre effektivt end den anden metode, der
>>>>> er givet, ved jeg ikke.
>>>>>
>>>>> Den anden metode ser ihvertfald mere elegant ud...
>>>> Join-metoden ovenfor er meget dyr.
>>> Det kommer bestemt an på, hvilke index der er på tabellen. Med et
>>> index på navn, vil det ikke kræve meget mere end et enkelt tablescan.
>> Jeg tvivler kraftigt på at et mangedobbelt join med passende
>> kriteriner nogen sinde vil kunne konkurrere med group by, da det er
>> nogle helt andre oplysninger, der skal holdes i hukommelsen, når
>> databasen behandler forespørgslen.
>
> Det kommer bestemt an på sammenhængen og det præcise indhold i det
> pågældende join. I det konkrete eksempel ser jeg ingen grund til at tro at
> det multiple join er tungt at udføre.
>
> Konkret:
>
> - Table scan af tbl instans a.
> - Filtrering på a.nummer
> - Indexeret opslag i tbl instans b
> - Filtrering på b.nummer
> - Indexeret opslag i tbl instans c
> - Filtrering på c.nummer
>
> Det er muligt de tre filtreringer alle kommer til sidst, men selv da vil det
> ikke være nogen performancemæssig katastrofe.
Det er lige min indvending og jeg er uenig med dig i at det ikke skulle
være nogen performancemæssig katastrofe. Jeg har temmelig svært ved at
se hvordan et flerdobbelt join af en tabel på sig selv ikke kan koste
dyrt - også med de korrekte indexes.
Men det er jo svært at afgøre uden flere konkrete oplysninger. Hvis der
aldrig vil være mere end nogle få tusinde rækker i tabellen, er det jo
temmelig akademisk.
Jeg synes at det er pudsigt at du argumenterer for en forespørgsel der
med stor sikkerhed ikke kan være hurtigere, end det jeg foreslår. Men
sådan er det selvfølgelig når man diskuterer teoretiske emner.
Desværre har jeg ikke rodet nok med performance tuning af databaser til
at kunne bidrage med noget særligt i den forbindelse. Den eneste
tommelfingerregel jeg virkelig går op i er at undgå mangedobbelte joins.
> Jeg prøver ikke at argumentere for at dette er den bedste løsning, men siger
> blot at argument "det er performancemæssigt dyrt" ikke holder vand.
Hvis du kan komme med et eksempel på at din forespørgsel performer lige
så godt som den jeg har foreslået, synes jeg at det er mere interessant
at diskutere videre.
> Det var heller ikke, hvad der var tale om.
>
> Eksemplet indeholdt specifikke tal som hhv. t1.nummer, t2.nummer osv. skulle
> være lig. Ikke noget problem.
>
>
Det har du ret i.
Mvh. Michael.
