Sql fråga

select * from tabell where grejj = 'bla' OR grejj = 'tjo'

de borde väl funka?

edit: eller: grejj like '%bla%' or grejj like '%tjo%'
om du måst eha de.

edit2: eller dom skulle innehålla båda orden? då blir de:
select * from tabell where grejj like '%bla%' AND grejj like '%tjo%'

Smäll in alla sökord i en array:

$keywords = array( 'test%', '%bajs%', 'test2' );

Sen kan du göra något sånt här kanske:

'SELECT * FROM bah WHERE habbu LIKE \''. implode( '\' OR habbu LIKE \'', $keywords ). '\''

Tänk dock på att sökningar med LIKE på stora textmassor är allt annat än snabbt. Om bra prestanda är ett krav borde du indexera sökorden på något vettigt sätt.

Tänk dock på att MySQL's fulltext index inte är tänkt som ett alternativ till en "riktig" sökmotor. Sökningar på fulltext-index i MySQL på stora datamängder är inte snabbt. Något jag lärde mig alldeles för sent i mitt forum och nu har fått fixa i efterhand.

Nu har jag iofs inte testat fulltext i MySQL 4 i någon större utsträckning, men jag tvekar på att de har förbättrat den så radikalt vad gäller prestanda. I MySQL 3.* är den nämligen helt obrukbart långsam. Jag laborerade lite med fulltext-sökningar i ett text-fält på detta forums databas (202000 inlägg var det då) och det var ingen rolig upplevelse (vi pratar flera sekunder på en P2-450/192mb här i mitt kök). Jag har nu kört i väggen vad gäller sökfunktionaliteten i mitt forum och jobbar för tillfället på att helt och hållet byta ut den.

Det finns utöver prestandaproblemet ett par andra saker som hindrar mig från att använda fulltext-index i mitt forum. Den första klara nackdelen är att väldigt få host:er använder MySQL 4. Den anses fortfarande vara beta och det kommer nog ta ett tag innan den lämnar detta stadium. En annan nackdel är att det inte finns någon möjlighet att styra vilka ord som skall och vilka som inte skall indexeras. För tillfället har MySQL bara en intern lista med engelska "stopwords" och är det svensk text man indexerar kommer det finnas en massa "brus" i indexet vilket sänker prestanda och minskar träffsäkerheten i en sökning. Det går att redigera denna lista, men då får man manuellt redigera en bit källkod och kompilera om. Inte direkt funktionellt om man kodar ett forum som andra ska använda (på olika språk). Den största nackdelen är nog dock att det är MySQL-specifikt. Alla olika databaser implementerar fulltextsökning på sitt eget sätt och det blir en hel del fulhack för att stöda flera olika RDBMS. Vissa databaser har inget fulltext-stöd alls förutom i form av externa plugins och moduler (mssql, postgresql...).

Mitt tips är som följer. Om man inte har något behov av att ha portabilitet gentemot andra databaser (och host:er) och om det man indexerar inte är stora textkolumner kan man mycket väl använda fulltext-index. I alla övriga fall bör man överväga att implementera en egen sökindexering.

Fan, nu lät det nästan som en rant. Det var det inte tänkt som

Du har nog missuppfattat mig. Jag pratar inte om att bara ignorera indexering och köra helt vanliga textsökningar med LIKE-operatorn. Jag pratar om att implementera en egen sökindexering istället för att använda den inbyggda. Följande svar fick jag på frågan varför sökningar i mitt fulltext-index var så långsamma och varför fulltextindexet inte dykte upp i nyckelkolumnen när man kör EXPLAIN:

"The 'index' just offers some extra functionality on-top of what is basically a 'LIKE' operator. It compares two strings and calculates the likeness, which you can then use to decide which records to select. But obviously the likeness depends on what you put into the 'MATCH' clause, so it cannot be pre-calculated and stored in an index they way you'd store the auto_increment value in an index. That means the database must re-calculate for every row, even if it turns out you only need one row out of 30 million.

If you have 200k records, the fulltext will calculate the likeness for all 200k rows, which will take time. In your case: 7 seconds.

This is what makes the fulltext as it is quite useless."

Ok. Då förmodar jag att man kommer ha flera olika cfg-filer för olika språk då eller? Aja, det viktiga är iaf att man får möjlighet att som användare välja vilket språk det är man använder. Man kan ju faktiskt köra mer än ett språk på en server

Nej, det är ett externt program som man måste köra samtidigt som SQL-servern. Sök efter "Microsoft Search Service" på den här sidan: http://stylusinc.com/website/microsoftSQL2000.htm

Innan du fattar beslut om huruvida du ska använda MySQL's fulltextindex eller inte bör du nog göra lite tester på ett större sökmaterial. Jag levde i uppfattningen att alla skript i mitt forum var blixtsnabba jämfört med t.ex. vbulletin. När jag väl smällde in 15000 användare, 18000 trådar och 200000 inlägg upptäckte jag snabbt att det inte riktigt var så. Framför allt var det fulltextsökningen som hade gått från supersnabb till odrägligt långsam.

En klassisk lösning på det är att utnyttja en väldigt stor textmassa (the_bible.txt t.ex) och göra slumpmässiga urklipp ur den.

Ok. Jag får väl installera 4:an och testa. Jag har dock svårt att tro att fulltext blivit tja, 10-15 gånger snabbare eller nåt sånt. Är det långsammare än så är det nämligen inte användbart.

Ok. Det kanske är så att fulltext nu faktiskt är ett riktigt index och inte bara en utökning av LIKE-operatorns funktion.

Du kan sluta anta att jag är en idiot nu.