kā panākt indeksētu LIKE '%substring%' funkcionalitāti

[gurkjis]

kā zināms, SELECT * FROM products WHERE article LIKE '%substring%' neizmanto indeksu, kā dēļ šāda meklēšanas operācija ir ļoti lēna pie liela ierakstu daudzuma. Zinu, ka LIKE 'prefix%' izmantos indeksu, taču tas neder - vajag lai meklē jebkur iekš stringa.

 

MySQL FULLTEXT indekss arī neder - tas prot meklēt tikai veselus vārdus.

 

Esmu skatījies uz http://www.sphinxsearch.com/ , kas pie attiecīgas nokonfigurešanas var meklēt substringus, taču šim mīnuss tāds,ka tad ir speciāli uz servera jāinstalē šis softs.

 

Kādas idejas, varbūt kāds saskāries ar līdzīgu problēmu ?

[codez]

Ja MySQL nespēj veikt šādu funkcionalitāti, tad bez papildus softu instalēšanas neiztikt.

Visdrīzāk nāksies izmantot Sphinx vai Lucene. šur tur manīts runājam arī par xapian

[marrtins]

Ja negrib likt papildus softus, tad jāindeksē pašam :) Ja man pāries slinkums (pārsvarā slinkums ir to skriptu aprakstīt), tad pie noderīgiem skriptiem iemetīšu savu variantu par meklētāju.

[Grey_Wolf]

Esmu skatījies uz http://www.sphinxsearch.com/ , kas pie attiecīgas nokonfigurešanas var meklēt substringus, taču šim mīnuss tāds,ka tad ir speciāli uz servera jāinstalē šis softs.

Vispar jau codez mineja, ka bes specila softa neiztikt, tik skjiet ka Spinx bija modulis ko vareja pievienot pasham MySql (sen tas bij, kad ar shamo kramejos)

Bet nu atrdarbiiba (mekleshanas) pieaug vismaz 10X (ja labi nokonfigure tad ari visas 100X )

Tik skjiet ka bija neliela problema ar to ka nacas katru reizi prindekseet to Spxins indeksu (ja nepievienoji vinju pie MySql) dazreiz tas nav buutiski, bet dazreiz tas ir kritiski :(

[rpr]

nu mēs te ar apache solr mazliet niekojamies. nav sql, tāpēc mazliet jāčakarējās, bet php pat bija speciāla bibliotēka šim servisam.

[Gints Plivna]

Kādas idejas, varbūt kāds saskāries ar līdzīgu problēmu ?

 

Jā es kā analītiķis esmu ntās reizes saskāries ar šādu problēmu jeb pareizāk izsakoties vēlmi no klienta puses. Mani argumenti līdz šim ir bijuši šādi:

1) mēs nebūvējam krustvārdu mīklu minēšanas sistēmu (piemēram, otrais burts a, tad 2 burti pa vidu, tad s)

2) atrast citu svarīgu kritēriju, kas būtiski samazina datu apjomu un tad ja nu ļoti gribās meklēt apakšvirkni samazinātajā kopā

3) ja nekas cits neatliek, tad skaidri un nepārprotami paziņot un fiksēt rakstiskā protokolā, ka šis pasākums būs lēns, bremzīgs un kas vēl ļoti svarīgi čakarēs ne tikai konkrēto lietotāju, bet diemžēl arī visus viņa kolēģus, jo tiem tiks norauti resursi, ko būs monopolizējis krustvārdu mīklu minētājs. Parasti pēc tam šī iespēja vismaz netiek likta kā noklusētā un/vai tikai spec gadījumos (tiesības piemēram tikai ierobežotam lietotāju loka, kas izceļas ar zināmām saprāta pazīmēm).

 

Protams, esmu gatavs piekrist, ka krustvārdu mīklu minēšanas sistēmām, arheoloģisko pētījumu sistēmām, šādām tādām izziņas iestādēm, iespējams, ka reizēm kaut ko tādu tiešām vajag :)

 

Gints Plivna

http://datubazes.wordpress.com