[Conth]

Någon som har ett bra tips om hur man effektivast söker i en tabell med många rader.

Jag har en tabell med t.ex. kolumner för; kön, födelsedatum, bostadsort och civilstatus.

Så vill jag att mina användare skall kunna välja sökbegrepp fritt. T.ex;
- Alla singeltjejer födda mellan 1970-1974
- Alla som är födda 1988 och bor i Göteborg
- etc etc

Mitt problem idag är att det blir seeega sökningar, eftersom jag inte kan(?!) ha index som täcker alla kombinationer.
Nu har jag det för de vanligaste sökningarna men inte för alla. Eftersom det är många rader blir sökningarna kraftödande...

Någon som har någon smart lösning på problematiken??

[WizKid]

En sak som kan vara värt att testa är att göra en sökning för varje sökvillkor och sen slå ihop dem. Börja med den som ger minst träffar.

Alla födda mellan 1970 - 1974. Du får en array av ID.
Alla singlar som finns i arrayn. ( SELECT ID FROM members WHERE status = "singel" AND ID IN(alla id från första sökningen) ). Du får en ny array av ID.
Alla tjejer som finns i arrayn.

Eftersom varje sökning nu kan använda index om du sätter ett index på varje kolumn kan det gå fortare. Jag har använt det för en liknande sak och det gick betydligt mycket fortare.

[MRDJ]

Originally posted by Conth@Jun 30 2006, 15:51
Någon som har ett bra tips om hur man effektivast söker i en tabell med många rader.

Jag har en tabell med t.ex. kolumner för; kön, födelsedatum, bostadsort och civilstatus.

Så vill jag att mina användare skall kunna välja sökbegrepp fritt. T.ex;
- Alla singeltjejer födda mellan 1970-1974
- Alla som är födda 1988 och bor i Göteborg
- etc etc

Mitt problem idag är att det blir seeega sökningar, eftersom jag inte kan(?!) ha index som täcker alla kombinationer.
Nu har jag det för de vanligaste sökningarna men inte för alla. Eftersom det är många rader blir sökningarna kraftödande...

Någon som har någon smart lösning på problematiken??

det går att bygga upp en sqlfråga beroende på vad användaren har valt att söka på.

sen alltid när det gäller databaser så är INDEXERING skit viktigt.
det blir sån jääkla skillnad när du byggt ett bra index.

bygg ditt index beroende på vad du har i where:satsen.


lite svårt att säga hur du skall bygga sqlfrågan när man inte vet hur strukturen ser ut

men som sagt.. index =)

[WizKid]

fredlund: Läste du ens Conth post? Han skriver:
"Mitt problem idag är att det blir seeega sökningar, eftersom jag inte kan(?!) ha index som täcker alla kombinationer.
Nu har jag det för de vanligaste sökningarna men inte för alla. Eftersom det är många rader blir sökningarna kraftödande..."

[MRDJ]

Originally posted by WizKid@Jun 30 2006, 19:52
fredlund: Läste du ens Conth post? Han skriver:
"Mitt problem idag är att det blir seeega sökningar, eftersom jag inte kan(?!) ha index som täcker alla kombinationer.
Nu har jag det för de vanligaste sökningarna men inte för alla. Eftersom det är många rader blir sökningarna kraftödande..."

oj, läste en aning fel.. hehe sorry

[digiArt]

Du skulle kunna bryta ut vanliga kombinationer till en egen tabell. Självklart blir det data som du ändå kunde lagrat i samma tabell som personinformationen, dvs risken blir att det blir redundant. Men är det data som uppdateras sällan är det bättre för sökprestanda att lägga det i egna tabeller eftersom sökning kanske sker oftare än uppdatering. Är det tvärtom, dvs uppdatering sker oftare än sökning bör du försöka slå ihop tabeller.

Men exempelvis skulle du kunna ha en tabell som lagrar id:n för vilka som är singlar. Då kan du köra en EXISTS.

Jag är ingen db-guru, men jag skulle iaf fundera i de banorna istället för att ha en bool i en tabell för singel eller ej.

Själv är jag en superfan av kopplingstabeller. (Och sen är EXISTS ett jättebra nyckelord istället för WHERE kolumn IN (...))

[Conth]

Tack för förslagen, jag får prova mig fram lite.

Jag har byggt en strippad söktabell idag med de vanliga sökvärdena i, problemet är ju att det är relativt mycket uppdateringar och det gör att jag får tyngre för varje nytt index jag lägger på...

[Blackex]

Originally posted by Conth@Jun 30 2006, 15:51
Mitt problem idag är att det blir seeega sökningar, eftersom jag inte kan(?!) ha index som täcker alla kombinationer.
Nu har jag det för de vanligaste sökningarna men inte för alla. Eftersom det är många rader blir sökningarna kraftödande...

Varför kan du inte sätta index på alla kolumner?

I mina öron låter det som att du har ett normaliseringsproblem..
dev.mysql.com/tech-resources/articles/intro-to-normalization.html

[tartareandesire]

Originally posted by Conth@Jun 30 2006, 23:00
Tack för förslagen, jag får prova mig fram lite.
Jag har byggt en strippad söktabell idag med de vanliga sökvärdena i, problemet är ju att det är relativt mycket uppdateringar och det gör att jag får tyngre för varje nytt index jag lägger på...

Tala gärna om vad som fungerar bäst ifall du hittar någon bra lösning, kommer själv råka ut för samma sak framöver...

[kullervo]

Jag förutsätter att du använder en av de vanligare SQL-databserna.

Det låter som det bara handlar om svenska personer. Eftersom det bara bor 10 miljoner pers i Sverige kan det inte vara problem med de där sökningarna. Släng på ett standardindex på alla kolumnerna, läs manualen till din databasmotor för index och se om du inte kan slänga in mer specifika index (booleska tänker jag på i första hand) när du tagit reda på vad de är vanligt att söka på. Så länge tabellen inte uppdateras mycket kan du köra massor av index men förmodligen räcker det med få väl utvalda istället.