Skip site navigation (1) Skip section navigation (2)

Re: Moet ik oppassen met wat ik index?

From: Ron Smeets <ron(dot)smeets(at)kensas(dot)nl>
To: pgsql-nl-algemeen(at)postgresql(dot)org, ron(dot)smeets(at)kensas(dot)nl
Subject: Re: Moet ik oppassen met wat ik index?
Date: 2010-06-04 08:09:41
Message-ID: 4C08B4C5.60806@kensas.nl (view raw or flat)
Thread:
Lists: pgsql-nl-algemeen

Op 3-6-2010 19:53, Isaak schreef:
>
>         Een index helpt het meest als hij alle velden bevat die in de
>         WHERE worden
>         gebruikt, op de manier waarop ze in de WHERE worden gebruikt.
>         Ga dus niet op elke kolom apart een index maken, maar verzamel
>         per index
>         een aantal kolommen die samen in een WHERE worden gebruikt.
>
>
> Als ik het goed begrijp hebben multi-kolom indexen geen effect hebben
> op SQL queries met WHERE clausules die niet gebruik maken van de meest
> linkse index. Als dit zo is, moet ik wel een aparte index maken voor
> elke veld die ik apart wil gebruiken in een WHERE clausule.
>
Het gaat erom dat je tenminste één where clause hebt die ervoor zorgt
dat er een index gebruikt wordt en er voor zorgt dat het aantal
resultaten zo snel mogelijk beperkt wordt. Ik neem aan dat je met de
"meest linkse index" bedoelt : het eerste veld in de index.

> Vb: Neem dat ik een index heb met volgende velden: naam,
> naam_oorspronkelijk & auteur, dan zal een query zoals SELECT * FROM
> boeken WHERE auteur = 'een naam'; niet gebruik maken van deze index,
> omdat deze niet gebruik maakt van het veld "naam" in de WHERE clausule.
>
Klopt, omdat de index pas gebruikt gaat worden als je ook het veld
"naam" gebruikt.

>     Als je geen PK hebt, hoe wijs jij dan aan welke records je wilt
>     verwijderen?
>
>
> Gewoon door een ander veld te gebruiken en indien deze niet uniek is
> een combinatie van velden. De tabel ter kwestie is een tabel die
> acties van gebruikers opslaat, acties zoals "gebruiker bezoekt pagina
> van boek x", of "gebruiker waardeert boek y".
>
>     Ik houd me niet zo bezig met boeken maar ik weet dat het
>     computer-collectief en selecties er een paar hebben.
>
>
> Ik ook niet meer tegenwoordig, moet ik eerlijk toegeven. Maar ik begin
> het wat vervelend te vinden dat veel nuttige info op het internet
> Engelstalige terminologieën bevatten. Hier verspil ik teveel tijd aan
> om de betekenis ervan op te zoeken.
>
>     Eerste wat bij mij opkomt is de vraag : is het nodig om tientallen
>     kolommen te hebben bij deze tabel, of kan er verder genormaliseerd
>     worden?
>
> Is het dan niet beter om zoveel mogelijk kolommen te maken die
> toepasselijk zijn voor deze tabel? Waarom deze opsplitsen en gebruik
> maken van lelijke JOINs?
>
Oeps... Normalisatie is de basis voor je modellering. Op basis van bijv.
performance criteria of beheeroverwegingen kun je later weer
denormaliseren. Maar dat dient altijd een bewuste ontwerpbeslissing te
zijn. Bestudeer http://nl.wikipedia.org/wiki/Databasenormalisatie.


> Kun je mij ook uitleggen wat je verstaat onder normalisatie? Ik ben
> niet echt bekend met deze term.
>
>     Verder inzake indexen : probeer niet te veel indexen aan te maken
>     op een
>     tabel. Elke extra index heeft impact op insert, update, delete
>     performance. Dit geldt voor ieder rdbms dus ook voor postgresql.
>     Je kunt
>     samengestelde indexen aanmaken, maar let daarbij op de volgorde van
>     velden in de index. Als je bijvoorbeeld een index aanmaakt op naam,
>     naam_oorspronkelijk, auteur en de where-clause van de query bevat
>     alleen
>     naam en auteur, dan wordt deze index niet gebruikt.
>     Dus het is zaak een overzicht te maken van alle belangrijke
>     where-clauses en daaruit af te leiden welke velden in aanmerking komen
>     voor indexering (al dan niet samengesteld).
>
> Ah, zoals boven vermeld dacht ik dat dit alleen toepasselijk was voor
> de meest linkse indexen. Is het dan beter om samengestelde indexen
> i.p.v. aparte te maken voor queries met meerdere WHERE clausules?
>
> Vb: SELECT * FROM boeken WHERE naam = 'postgresql' && auteur =
> 'ikkeniet'; met een B-tree index dat bestaat uit naam & auteur of twee
> aparte indexen van deze velden? Indien toch de eerste de beste manier
> is biedt dit toch minder flexibiliteit dan twee aparte indexen? Dan
> kan ik toch ook van deze indexen gebruik maken met queries die alleen
> één van deze velden doorzoeken?
>
Klopt, maar in het onderhavige geval zou ik kiezen voor een
samengestelde index. Dat betekent in de praktijk dat als je auteur
gebruikt moet je ook naam gebruiken. Alles hangt natuurlijk af van wat
de gewenste functionaliteit is van je applicatie.

>     Primaire sleutels zijn altijd een must, een index op een foreign
>     key is
>     ook altijd een must.
>
>
> Bedoel je dan een index plaatsen op de velden waarvan de foreign keys
> gebruik maken? Indien wel, dan is dit geen probleem want ik heb nog
> geen enkele keer een foreign key moeten maken die niet gebruik maakt
> van een PK van een tabel (en eerlijk gezegd heb ik gisteren pas leren
> werken met foreign keys omdat ik dit altijd deed in pure PHP code).
>
>
>     Indien je werkt met een volledig vrije interface voor
>     eindgebruikers kun
>     je overwegen om een extra kolom toe te voegen van het type
>     ts_vector. In
>     deze kolom neem je dan alle relevante velden op. Deze kolom gebruik je
>     voor de zoekacties (dus moet er een index op). Zie :
>     http://www.postgresql.org/docs/8.4/static/textsearch.html. Hiermee kun
>     je op een eenvoudige wijze google-achtige zoekacties verwezenlijken.
>
>
> Met het tsvector datatype heb ik helaas nog geen ervaring en ik
> begrijp het hele concept ook nog niet zo goed. Indien ik zo'n kolom
> zou aanmaken moet ik dan gewoon alle velden waarin gebruikers moeten
> kunnen zoeken opslagen in deze kolom? Zal dit dan niet veel
> ontoepasselijke resultaten opleveren als ik ook de beschrijvingen van
> boeken in deze kolom opsla?

Text search is een onderwerp dat je moet bestuderen. Je kunt inhoud van
boeken, uitreksels, naam auteur, etc. allemaal opslaan in een apart text
veld. Hierop kun je een index leggen. Zoeken wordt dan eenvoudig :
binnen dit ene tekstveld. Je krijgt een google-achtige uitkomt met
ranking van de resultaten.

Groet,
Ron Smeets
Kensas bv

In response to

Responses

pgsql-nl-algemeen by date

Next:From: IsaakDate: 2010-06-05 19:10:59
Subject: Re: Moet ik oppassen met wat ik index?
Previous:From: vinnyDate: 2010-06-03 19:25:11
Subject: Re: Moet ik oppassen met wat ik index?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group