Re: Moet ik oppassen met wat ik index?

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.

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.

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?

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?

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?