[eg0master]

Min erfarenhet är att väldigt många som "jobbar med web" envisas med att använda strängar stup i kvarten i sina databaser för saker som inte bör vara strängar. Dvs att man har en "varchar(4)" för födelseår till exempel (eller varchar(8) för födelsedatum). Sådant kan avsevärt försämra effektiviteten av index då sökningar på tal (inkl datum) oftast är betydligt mer effektiva.

Har du till exempel "Göteborg" som en text i din tabell eller är hemorten bara ett ID som refererar till ortstabellen? Det är ett annat typiskt "webfenomen" (dvs att inte normalisera i tillräcklig utsträckning).

Annars är det nog som någon föreslog att det bästa är att istället för flera olika index med flera kollumner enbart ha ett index per kollumn. Databasmotorn kommer sannolikt välja ett av indexen som ger minsta submängd att jobba vidare med (dvs har du bara två från göteborg väljs dessa ut först om du har 100 födda 1988).

[Conth]

Originally posted by kullervo@Jul 1 2006, 15:02
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.

Jo det är mysql 5

Som jag sa tidigare så uppdateras tabellen tämligen ofta, vilket gör att jag inte vill slänga på för många index.

Dessutom funkar det inget vidare med många index...
Säg att jag vill kunna söka på en kombination av 5 olika termer. t.ex. A-E
Jag kan ju inte ha ett index för A+B+C, ett annat för A+D+E, ett tredje för B+C+E etc etc. Om man sedan dessutom vill kunna sortera resultatet (blanda sortering ASC, DESC) måste det till en tablesort även om jag har rätt index.

Det enda jag kan göra(?) är det jag gjort nu tagit de vanligaste sökbegreppen och lag index på dom, men det ger fortfarande en hel del sökningar som hamnar i slow-loggen...

Min erfarenhet är att väldigt många som "jobbar med web" envisas med att använda strängar stup i kvarten i sina databaser för saker som inte bör vara strängar. Dvs att man har en "varchar(4)" för födelseår till exempel (eller varchar(8) för födelsedatum). Sådant kan avsevärt försämra effektiviteten av index då sökningar på tal (inkl datum) oftast är betydligt mer effektiva.

Bra tips, ska dubbelkolla att jag inte missat någon här.

[martine]

Originally posted by Conth@Jul 2 2006, 23:43

Bra tips, ska dubbelkolla att jag inte missat någon här.

Att använda DATE och YEAR osv är väl en självklarhet. Jag har haft ganska bra erfarenhet av ENUM (som lagras binärt) även om jag egentligen har några säkra uppgifter för effektivitet i sökningar. Det lär ju i alla fall löna sig att välja sina lagringstyper med omsorg.

[eg0master]

Originally posted by martine@Jul 3 2006, 02:23
Att använda DATE och YEAR osv är väl en självklarhet. [...] Det lär ju i alla fall löna sig att välja sina lagringstyper med omsorg.

Jag skulle önska att det var så, men tyvärr hittar jag varchar allt för ofta i system gjorda av "webprogrammerare"...

[Blackex]

Originally posted by eg0master@Jul 2 2006, 22:54
Dvs att man har en "varchar(4)" för födelseår till exempel (eller varchar(8) för födelsedatum). Sådant kan avsevärt försämra effektiviteten av index då sökningar på tal (inkl datum) oftast är betydligt mer effektiva.

Fler tips:

- Byt ut varchar(NUMMER) mot char(NUMMER). Då tar alla rader lika mycket plats, vilket gör att databasen inte blir så fragmenterad.
- Använd OPTIMIZE TABLE regelbundet

[eg0master]

Att använda char istf varchar blir man ju vansinnig av. Det blir ett satans trimmande hela tiden. Jag skulle starkt avråpde från att använda char för annat än väldigt korta och garanterat exaklt lika långa värden (t.ex. bokstavsförkortningar för stater i USA eller Län i sverige).

I alla de system jag någonsin varit med och utveckla (och då vill jag påminna om att det inte är web som är min huvudsyssla utan andra typer av system) har jag aldrig själv eller sett någon annan använda char istf varchar.

[Blackex]

Vad menar du med "trimmande"?

Saxat från http://dev.mysql.com/doc/refman/5.0/en/data-size.html:

For MyISAM tables, if you do not have any variable-length columns (VARCHAR, TEXT, or BLOB columns), a fixed-size row format is used. This is faster but unfortunately may waste some space.

[eg0master]

Med trimmande menar jag att om du använder char för något som egentligen är av variabel längd lär du vilja trimma bort space för att kunna göra vettiga jämförelser/utskrifter. Jämför funktionen "trim" som förekommer i de flest språk (i anslutning till strängar).

Och vad är det du saxat egentligen? Vad vill du säga med det? Ärligt talat tycker jag det är ofta du Blackex kommer med inlägg som känns gripna ur luften och inte alltid helt relevanta. Ibland (som i detta fall) känns det mer som ett reultat av en googling än ett relevant svar. En orsak skulle kunna vara att du (liksom jag gör ibland) tänker i flera steg och att dina inlägg saknar några associationssteg och därför blir obegripliga.

[Blackex]

Med trimmande menar jag att om du använder char för något som egentligen är av variabel längd lär du vilja trimma bort space för att kunna göra vettiga jämförelser/utskrifter. Jämför funktionen "trim" som förekommer i de flest språk (i anslutning till strängar).

Trimmningar behöver ej göras. Att välja CHAR istället för VARCHAR har endast betydelse "bakom kulisserna", dvs i databasen. När du hanterar datan så blir det alltså inte en massa onödigt tomrum. Ur användningshänseende är alltså CHAR och VARCHAR exakt lika. För att vara extra tydlig, du behöver alltså inte använda trim() eller motsvarande funktion för att tömma strängen på extra fluff

Och vad är det du saxat egentligen? Vad vill du säga med det? Ärligt talat tycker jag det är ofta du Blackex kommer med inlägg som känns gripna ur luften och inte alltid helt relevanta. Ibland (som i detta fall) känns det mer som ett reultat av en googling än ett relevant svar. En orsak skulle kunna vara att du (liksom jag gör ibland) tänker i flera steg och att dina inlägg saknar några associationssteg och därför blir obegripliga.

Du har förmodligen rätt Jag trodde att jag var tydlig. Jag saxade från MySQL manualen. MySQL, antar jag, är den databas som de flesta här använder. Sidan som jag saxade ifrån handlar om hur man får bättre prestanda genom att använda olika tekniker.

Dokumentationen bekräftar alltså det som jag säger. Allt kolumner med fast storlek går snabbare att accessa. Använder du VARCHAR tar det mindre utrymme, men går långsammare. Därav mitt ursprungliga tips om att använda CHAR och inte VARCHAR.

Förstår du relevansen nu?

[eg0master]

Trimmningar behöver ej göras. Att välja CHAR istället för VARCHAR har endast betydelse "bakom kulisserna", dvs i databasen.

Kul att man får lära sig något nytt. MySQL är helt klart magisk. Vad praktiskt (om man nu inte mot förmodan vill behålla "traling space" i databasen). Ja då minskar definitivt anledningen till att använda varchar för mysql.
Har inte testat MSSQL, för jag är definitivt säker på att det åtminstopne i tidigare versioner av någon databas jag jobbat med (Men jag kan i nuläget inte minnsa om det varit Access, MSSQL eller Sybase) som inte strippat space från char på det sätt MySQL gör.
Eftersom diskplats är billigt så är definitivt char ett lämpligt alternativ till varchar för att förbätgtra prestanda.

Förstår du relevansen nu?

Absolut.