---

Jeg skal lave noget tekst-søgning i MySQL og er derfor ikke interesseret i
at søgningen er case-sensitive, sådan som det er standard i MySQL.

Findes der nogle mulighed? Har tænkt på at uppercase tekst-strengene, men
dette er næppe den mest fornuftige metode.

- Daniel

---

On Thu, 1 Dec 2005 18:04:07 +0100, "news.cybercity.dk" <Daniel Overby>
wrote:

>Jeg skal lave noget tekst-søgning i MySQL og er derfor ikke interesseret i
>at søgningen er case-sensitive, sådan som det er standard i MySQL.

Som standard er søgninger på tekstfelter i MySQL *ikke*
case-sensitive, så det burde ikke være et problem.

Det forudsætter altså, at du benytter dig af tekstfelter som fx CHAR,
VARCHAR, TINYTEXT, TEXT, etc. og ikke af binary-felttyperne,
deriblandt BLOB-typerne.

--
- Peter Brodersen

---

> Som standard er søgninger på tekstfelter i MySQL *ikke*
> case-sensitive, så det burde ikke være et problem.

Hmm... i givet fald vil jeg håbe min arbejdsgiver ikke har opdaget jeg har
været beruset på arbejdspladsen! :)

> Det forudsætter altså, at du benytter dig af tekstfelter som fx CHAR,
> VARCHAR, TINYTEXT, TEXT, etc. og ikke af binary-felttyperne,
> deriblandt BLOB-typerne.

Der er tale om varchar.

- Daniel

---

On Thu, 1 Dec 2005 18:38:14 +0100, "news.cybercity.dk" <Daniel Overby>
wrote:

>> Som standard er søgninger på tekstfelter i MySQL *ikke*
>> case-sensitive, så det burde ikke være et problem.
>Hmm... i givet fald vil jeg håbe min arbejdsgiver ikke har opdaget jeg har
>været beruset på arbejdspladsen! :)

Det sker

>> Det forudsætter altså, at du benytter dig af tekstfelter som fx CHAR,
>> VARCHAR, TINYTEXT, TEXT, etc. og ikke af binary-felttyperne,
>> deriblandt BLOB-typerne.
>Der er tale om varchar.

Den er ikke case-sensitive, medmindre den er blevet oprettet som
binary/med binary collation.

Ellers vil det virke uden videre:

mysql> CREATE TABLE test (foo VARCHAR(20) );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO test (foo) VALUES ('Peter');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM test WHERE foo = 'peTeR'\G
*************************** 1. row ***************************
foo: Peter
1 row in set (0.00 sec)

--
- Peter Brodersen

---

> Den er ikke case-sensitive, medmindre den er blevet oprettet som
> binary/med binary collation.

Hvis et af felterne nu er BINARY, hvad gør man så?

- Daniel

---

On Mon, 5 Dec 2005 16:46:49 +0100, "news.cybercity.dk" <Daniel Overby>
wrote:

>> Den er ikke case-sensitive, medmindre den er blevet oprettet som
>> binary/med binary collation.
>Hvis et af felterne nu er BINARY, hvad gør man så?

Enten retter du feltet til et mere passende felt, eller også benytter
du dig af UPPER (eller LOWER) på søgeord og data. Det lader til at
virke fint, også med æøåÆØÅ, selv på gamle MySQL'er (har testet på en
ny 5.0 med dansk collation, og på en gammel 3.23)

Hvad indeholder det felt mere præcist? Hvis det er meget store mængder
data, kan det være at fulltext-indekseringen er mere interessant.
Varchar-felter kan dog kun rumme 255 tegn (dog 65.535 i MySQL 5.0), så
hvis det ikke er et spritnyt projekt, så går jeg ikke ud fra at hvert
felt rummer så meget data trods alt.

Fulltext-indeksering kan ikke benyttes på blob-felter, men godt på
varchar-kolonner som dit (og char- og text-kolonner), også selv om de
er angivet som binary (= med binary collation).

--
- Peter Brodersen

---

> Hvad indeholder det felt mere præcist? Hvis det er meget store mængder
> data, kan det være at fulltext-indekseringen er mere interessant.
> Varchar-felter kan dog kun rumme 255 tegn (dog 65.535 i MySQL 5.0), så
> hvis det ikke er et spritnyt projekt, så går jeg ikke ud fra at hvert
> felt rummer så meget data trods alt.

Det felt, jeg vil have fri-søgning på er en binary varchar(255). Jeg har
lavet et alm. index på kolonnen, hvilket forbedrede ydelsen betragteligt.
Jeg vil tro at der i snit er omkring 10.000 tupler i tabellen.

> Fulltext-indeksering kan ikke benyttes på blob-felter, men godt på
> varchar-kolonner som dit (og char- og text-kolonner), også selv om de
> er angivet som binary (= med binary collation).

Kan det betale sig at bruge fulltext-indeksering? I run-time har jeg kun
selects på tabellen - mine update, insert og delete kører i daglige batch
jobs.

- Daniel

---

On Tue, 6 Dec 2005 18:00:25 +0100, "news.cybercity.dk" <Daniel Overby>
wrote:

>Det felt, jeg vil have fri-søgning på er en binary varchar(255). Jeg har
>lavet et alm. index på kolonnen, hvilket forbedrede ydelsen betragteligt.
>Jeg vil tro at der i snit er omkring 10.000 tupler i tabellen.

Det forbedrer det i hvert fald, hvis det er det præcise indhold (eller
begyndelsen af teksten vha. LIKE), der søges på.

Hvis der ikke er nogen grund til at feltet er binary, kan du jo
overveje at ændre det. En anden mulighed er at sætte en collation
on-the-fly i selve forespørgslen, vha. COLLATE:
http://dev.mysql.com/doc/refman/5.0/en/charset-collate.html

Rent semantisk mener jeg at det er pænere end at bruge UPPER.

>> Fulltext-indeksering kan ikke benyttes på blob-felter, men godt på
>> varchar-kolonner som dit (og char- og text-kolonner), også selv om de
>> er angivet som binary (= med binary collation).
>Kan det betale sig at bruge fulltext-indeksering? I run-time har jeg kun
>selects på tabellen - mine update, insert og delete kører i daglige batch
>jobs.

Det er lidt smag og behag.

I mine øjne er bl.a. søgninger på websider irregulære operationer, der
specielt i forbindelse med websider godt må tillade at være lidt
sløvere for bedre resultater.

Her kan det være, at man er interesseret i at søge i delmængder af ord
i teksten, hvor LIKE-søgninger på %søgeord% rent faktisk er at
foretrække frem for fuldtekst-indekseringer. Omvendt set kan
fuldtekst-indekseringer give en logisk fleksibilitet med flere
søgeord, vægt af resultater, m.m.

Det kan godt tænkes, at operationstiden fx stiger fra 0.01 sekund til
0.1 sekund ved LIKE-opslag, hvilket proportionelt kan virke voldsomt,
men i forbindelse med webresultater er det ikke nødvendigvis noget,
brugeren lægger mærke til. Igen, lige præcis ved søgninger har jeg det
fint med at applikationen bruger lidt ekstra energi på at levere
fornuftige resultater.

En detalje er selvfølgelig, at LIKE-søgningerne ikke skalerer så godt,
men at belastningen stiger lineært med mængden af indhold i kolonnen.
Det er så et spørgsmål om man får store mængder ny data ind, og om ens
database-server i øvrigt har sved på panden. I et andet projekt laver
jeg nogle ganske ressourcekrævende operationer i forbindelse med
søgninger (blandt andet tekstsammenligninger uden for databasen med
similar_text() i PHP). Det kræver langt flere ressourcer, men
resultatet er tilsvarende langt bedre - og den mængde ressourcer, der
kræves, er i øjeblikket godt inden for hvad jeg finder acceptabelt.

Hvis det dog skal være et pænt setup, der skalerer i det uendelige, så
er fulltext-indeksering det rette valg. Jeg forudsætter her, at der
skal kunne søges på bestemte ord inde i felterne, og ikke blot
begyndelsen af felterne (hvor et almindeligt indeks er fint nok).

En anden detalje er, at du i det setup helt sikkert bør sikre dig, at
du har querycachen aktiveret (hvis du minimum bruger MySQL 4.0). Det
er meget optimalt, idet du har "sjældne"
datamanipulations-operationer.

--
- Peter Brodersen