|
|
 | Index på alle felter
Fra : Henrik Stidsen |
Dato : 28-09-06 09:04 |
|
Jeg kom lige til at tænke på...
Er det dårligt design når man ender med at have brug for indexes på
samtlige felter i en tabel ?
Det kan f.eks. være en tabel der benyttes i mange forskellige
sammenhænge og derfor også med forskellige select statements således
at alle felter i en eller anden sammenhæng benyttes til at udvælge
data.
| |
 Jens Gyldenkærne Cla~ (28-09-2006)
| Kommentar
Fra : Jens Gyldenkærne Cla~ |
Dato : 28-09-06 10:21 |
|
Henrik Stidsen skrev:
> Er det dårligt design når man ender med at have brug for
> indexes på samtlige felter i en tabel ?
Det afhænger vel af hvor mange felter der er tale om - og hvor ofte
tabellen ændres.
Et index vil generelt betyde hurtigere udvælgelser (forudsat at
indekset kan benyttes i udvælgelsen) men langsommere
handlingsforespørgsler.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen
| |
Christian Bohr-Halli~ (28-09-2006)
| Kommentar
Fra : Christian Bohr-Halli~ |
Dato : 28-09-06 21:24 |
|
Jens Gyldenkærne Clausen <jens@gyros.invalid> posting:
>Et index vil generelt betyde hurtigere udvælgelser (forudsat at
>indekset kan benyttes i udvælgelsen) men langsommere
>handlingsforespørgsler.
Hvad mener du mere konkret med "handlingsforespørgsler"?
--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt
Fly Opera - http://www.opera.com/
| |
 Henrik Stidsen (28-09-2006)
| Kommentar
Fra : Henrik Stidsen |
Dato : 28-09-06 22:00 |
|
on 28-09-2006, Christian Bohr-Halling supposed :
>> Et index vil generelt betyde hurtigere udvælgelser (forudsat at
>> indekset kan benyttes i udvælgelsen) men langsommere
>> handlingsforespørgsler.
> Hvad mener du mere konkret med "handlingsforespørgsler"?
Mon ikke det er UPDATE, INSERT og DELETE ? Ved de forespørgsler skal
indexet jo opdateres, det skal det ikke ved et SELECT.
--
Henrik Stidsen - http://henrikstidsen.dk/
"I told the doctor I broke my leg in two places. He told me to quit
going to those places." - Henny Youngman
| |
Christian Bohr-Halli~ (28-09-2006)
| Kommentar
Fra : Christian Bohr-Halli~ |
Dato : 28-09-06 23:12 |
|
Henrik Stidsen <nntpspam@hs235.dk> posting:
>Ved de forespørgsler skal indexet jo opdateres, det skal det ikke ved et SELECT.
Nok skal det opdateres, men det behøver ikke være værre end en
udvælgelsesforespørgsel rent disklæsningsmæssigt, så længe man ikke
i forb. hermed har brug for at udføre en "vedligeholdelse" af
datastrukturen (som fx knude-opdeling ved et B+ træ).
--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt
Fly Opera - http://www.opera.com/
| |
Jens Gyldenkærne Cla~ (28-09-2006)
| Kommentar
Fra : Jens Gyldenkærne Cla~ |
Dato : 28-09-06 22:12 |
|
Henrik Stidsen skrev:
>> Hvad mener du mere konkret med "handlingsforespørgsler"?
>
> Mon ikke det er UPDATE, INSERT og DELETE ?
Præcis. Handlingsforespørgsler er forespørgsler der udfører en
handling i databasen. Modsætningen er udvælgelsesforespørgsler
(SELECT) der blot læser fra databasen.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html
| |
Christian Bohr-Halli~ (28-09-2006)
| Kommentar
Fra : Christian Bohr-Halli~ |
Dato : 28-09-06 23:12 |
|
Jens Gyldenkærne Clausen <jens@gyros.invalid> posting:
>Præcis. Handlingsforespørgsler er forespørgsler der udfører en
>handling i databasen.
Har nu aldrig hørt dem omtalt sådan, men ok.
--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt
Fly Opera - http://www.opera.com/
| |
Jens Gyldenkærne Cla~ (29-09-2006)
| Kommentar
Fra : Jens Gyldenkærne Cla~ |
Dato : 29-09-06 08:02 |
|
Christian Bohr-Halling skrev:
>> Præcis. Handlingsforespørgsler er forespørgsler der udfører en
>> handling i databasen.
>
> Har nu aldrig hørt dem omtalt sådan, men ok.
Det er muligvis MS-terminologi - det anvendes i hvert fald bl.a. i
onlinehjælpen til Access. Jeg har set og anvendt betegnelsen i
mange år.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen
| |
Peter Brodersen (28-09-2006)
| Kommentar
Fra : Peter Brodersen |
Dato : 28-09-06 23:23 |
|
On 28 Sep 2006 01:04:12 -0700, "Henrik Stidsen"
<henrikstidsen@gmail.com> wrote:
>Det kan f.eks. være en tabel der benyttes i mange forskellige
>sammenhænge og derfor også med forskellige select statements således
>at alle felter i en eller anden sammenhæng benyttes til at udvælge
>data.
Det er sjældent, at man vitterligt har behov for indexes på alt. I
nogle tilfælde er dataen ikke spredt nok til at der er den store
forskel.
Det kan dog tænkes, at du har behov for indexes i sammenhæng, og
derfor er bedre tjent med at lave et index hen over flere felter:
Hvis du har en liste med en masse navne, hvor fornavn og efternavn er
opdelt i forskellige felter, kan et opslag på "Thomas, Hansen" måske
resultere i 500 resultater for fornavnet og 1.000 for efternavnet. Her
vil den optimalt vælge fornavns-indexet og så manuelt gennemgå de 500
"Thomas"-rækker for at finde dem med efternavnet "Hansen".
MySQL 5.0 (og diverse andre RDBMS'er) kan lave index_merge-opslag. Her
kan den finde fællesmængden af de hhv. 500 og 1.000 fundne rækker. Det
er dog ikke altid, at det vil være hurtigt end manuelt at løbe de 500
rækker igennem.
I et sådan tilfælde kan det være hensigtsmæssigt at lave et index hen
over flere felter, fx "fornavn, efternavn" eller "efternavn, fornavn".
Så vil man direkte på indexet kunne finde de par enkelte "Thomas,
Hansen"-rækker, der måtte være.
Du kan derfor overveje, om der er nogle kombinationer af felter i
opslagene, der er naturlige.
--
- Peter Brodersen
Kendt fra Internet
| |
Thorbjørn Ravn Ander~ (29-09-2006)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 29-09-06 06:56 |
|
Peter Brodersen <usenet2006@ter.dk> writes:
> I et sådan tilfælde kan det være hensigtsmæssigt at lave et index hen
> over flere felter, fx "fornavn, efternavn" eller "efternavn, fornavn".
> Så vil man direkte på indexet kunne finde de par enkelte "Thomas,
> Hansen"-rækker, der måtte være.
Mange databaser kan udæskes om en forklaring på hvad de har gjort og
hvorfor for at opfylde en forespørgsel.
Kan MySQL efterhånden det?
--
Thorbjørn Ravn Andersen
| |
Henrik Stidsen (29-09-2006)
| Kommentar
Fra : Henrik Stidsen |
Dato : 29-09-06 07:59 |
|
Thorbjørn Ravn Andersen skrev:
> Mange databaser kan udæskes om en forklaring på hvad de har gjort og
> hvorfor for at opfylde en forespørgsel.
> Kan MySQL efterhånden det?
Ja, med EXPLAIN kommandoen foran en forespørgsel giver databasens plan
for hvordan den vil udføre den konkrete forespørgsel, hvilke keys den
vil bruge, hvilke indexes osv.
Det har været med i hvert fald siden 4.0
| |
Henrik Stidsen (29-09-2006)
| Kommentar
Fra : Henrik Stidsen |
Dato : 29-09-06 07:59 |
|
Thorbjørn Ravn Andersen skrev:
> Mange databaser kan udæskes om en forklaring på hvad de har gjort og
> hvorfor for at opfylde en forespørgsel.
> Kan MySQL efterhånden det?
Ja, med EXPLAIN kommandoen foran en forespørgsel giver databasens plan
for hvordan den vil udføre den konkrete forespørgsel, hvilke keys den
vil bruge, hvilke indexes osv.
Det har været med i hvert fald siden 4.0
| |
|
|