Fulltext search! Vai vajag tabulas tipu Binary?

[Gacha]

Kā daudzās lapās, ts. arī manējā rādās vārdadienas, pie reizes izveidoju vārdadienu meklēšanu, jo nezināju kad pāris draugiem ir vārdadienas.

 

Nu protams viss strādā, bet ir daži brīnumi - meklēju vārdu Jānis un Līga, bet šis man tos neatrod, bet pārējos gan! Kaut kur lasiju, ka labāk laukam piešķirt atribūtu BINARY, jo tad tas salīdzina datus nevis burtus, bet es ar phpmyadmin mēģināju to izdarīt un nesanāca, laikam tapēc, ka lauki ir pilni un to vajag darīt tabulas izveidošanas brīdī! Piebildīšu, ka enkodings iekš DB ir UTF-8 un lapai ari UTF-8.

 

SQL => Select * from tabula where MATCH(vardi) AGAINST('Jānis')

 

---------------------------------------

Vēl pamaniju, ka ja lauka tips ir Longtext, tad tam fulltext nevar piešķirt. Tapēc rodas jautājums, kādu lauka tipu izmantot visslabāk tādiem laukiem, kur glabājas raksti - līdz šim izmantoju longtext(jo izklausās - long), bet tagad laikam lietošu text, jo var fulltext

[bubu]

Manuālī neesi skatījies?

longtext = text tipa, max 4 GB datu

text = max 64 KB datu

 

a ne ar ko citu kā garumu, tie tipi neatšķiras

Vārdadienas labāk glabā VARCHAR laukā un meklē šādi: SELECT * FROM tabula WHERE lauks LIKE '%Jānis%'

 

Edit:

Binary atribūts norāda tikai to, ka salīdzinot lauku vērtību vajag ņemt vērā lielos/mazos burtus tb ar BINARY 'a' <> 'A', bet ja nav BINARY, tad 'a' = 'A'

Edited August 26, 2004 by bubu

[Gacha]

Nop bubu, labāk meklēt ar MATCH, jo tu meklē Jānis, bet šis tev vēl izmet Krišjānis, kuru tev nevajaga.

[Venom]

BINARY iet pie SELECTa

 

fulltext varētu melot, ja mysql versija <4.1 vaikādatur, vienkārši tādēļ kā "ā" tiek "salikts" uz diviem burtiem

 

Un vispār - man kaukā FULLTEXT iespējas maz kur vajadzēja (parasti ar LIKE||= pietiek). Turklāt MATCH laikam būs vienmēr kautkāds, kaut vai 0.(0)1

 

kādu lauka tipu izmantot visslabāk tādiem laukiem, kur glabājas raksti

pēc ideoloģijas. izdomājam, cik tas teksts mums varētu būt garš (un kādā valodā). Tālāk, ja mysqls pilnībā neatbalsta MySQL, jāņem vērā, ka katrs "nestandarta" burts varētu tikt saglabāts kā 2 baiti. Resp, ka teksti pārsvarā krieviski - jāparedz lauka garums kā txt_length*2, ja latviskie ~ 1,6.

 

Es, laikam, nekur vairāk par MEDIUMTEXT neesmu izmantojis.

 

TEXT - a BLOB or TEXT column with a maximum length of 65535 (2^16 - 1) characters. Resp. 64Kb teksta (vai ~ 32 tūkst.zīmju UTF-8)

 

MEDIUMTEXT - a BLOB or TEXT column with a maximum length of 16777215 (2^24 - 1) characters. ~16Mb!

 

LONGTEXT - 4294967295 (2^32 - 1) characters - ~4Gb.

 

ja nemaldos kalkulējumos

 

vari salīdzināt ar vidējo Word dokumentu garumu ;)

[bubu]

UTF-8 vairumā gadījumu būs 1 baits (latviešu tekstam). Tikai mīkstajiem/garajiem burtiem būs 2 vai vairāk. Krievu tekstam gan taisnība, ka vajadzēs vismaz 2 vairāk vietas.

[Gacha]

Man nav ne jausmas, kāda mysql versija ir uz tās kastes, bet domājams, ka diezgan jauna. Nu, bet kapēc, tad man atrod vārdu Mārtiņš? šim pat ir 3 burti ar mīktinājuma zīmi.

 

Kas šis pa kodejumu, vai šifrējumu => header('Location: āčķļū') iznākums ir kaut kāds C%D... Domāju, ja DB saglabātu šitādi, tad atrast nebūtu problēma.

 

Vai arī varētu pašai DB uzlikt to UTF-8?

[Venom]

nu es latviešu tekstam kaut kad taisīju testu "cik vidēji sanāk nelatīņu burti"

kāds var pamēģināt arī pats, ar kaut ko līdzīgu.

[Venom]

par to arī iet runa - internal encoding

 

kad slēdzies klāt ar kādu klientu (MySQL Front%2

[Gacha]

Nu iepētiju to mysql. Versija ir 4.0.20 un charset=latin1 vai vajadzētu, vai tas būtu labi, vai varētu uzlikt to charset UTF-8 ? Kāds tolks būtu?

[bubu]

Tolks būtu tāds, ka burts ā tiktu uztverts kā burts ā. A bet ar ne UTF-8 kodējumu tas tiek uztverts, kā divu neatkarīgu baitu (ne-burtu) virkne. Šī iemesla dēļ tādas funkcijas kā rindas garums (LENGTH) vai burtu izgriešana pēc pozīcijas un garuma (SUBSTR) darbosies nekorekti!

[Venom]

Vai arī varētu pašai DB uzlikt to UTF-8?

par to arī iet runa - internal encoding

 

kad latin-1, tad vārdi tiek sašķelti pa vienam baitam, kad utf-8, tad pa diviem, resp.

ja utf-8 burts ā izskatās kā, piemēram 123 58 (skaitļi izdomāti), tad iekš latin-1 tie būtu 2 burti - 123 un 58, piemēram "t" un "r". Tā arī 'Jānis' vietā meklētu 'Jtrnis'

[Venom]

mums pēdējā laikā ar bubu baigi simultāni sanāk ;)

[Gacha]

Tagad bik patestēju un izrādās, ka ar like tas tomēr atrod to Jānis, bet atrod arī krišjānis :( Zinu, ka tas ir tapēc, ka tas salīdzina burtus, nevis vārdus. Vai tur nevar kaut ko darīt, lai viņš meklētu tikai pilnus vārdus? (sorry, bet google un mysql.com man pagaidām nav pieejamas).

 

PS. Tas tiesa, ka jūs abi pēdējā laikā taisāt baigās sacensības un izskatās, ka jūs ar katru dienu paliekat arvien gudrāki :) Es nez, kur jums viss šis lien galvā :D

[Venom]

nu tās nav sacensības, bet saucās "visu darba dienu sēžam pie datora un čekojas mails un rss"

 

att. uz saiet galvā: tas laikam saucās pieredze

 

att. uz meklēt kā atsevišķu vārdu.

cik saprotu, tev iekš tās db. iraid ierakstīts, piem.

26 augusts|Natālija, Tālija, Broņislavs, Broņislava

a jābūt ta:

26 aug.|Natālija

26 aug.|Tālija

... - tabulu racionalizēšana saucās

 

bet labi, ja tev ir kā ir, tad tev būs vairāki varianti:

 

ā) LIKE ar OR gadījumi:

'%, '.$name - kad name ir pēdejais rindā

$name.', %' - kad pašā sākumā

'%, '.$name.', %' - kad pa vidu

un of coss neizpaliek ari parasts = $name, ja ir tikai viens vārds

 

bē) FIND_IN_SET($name,`collonna`), kur kolonnā ir tieši comma-separated list

 

cē) vienkāršs LIKE vai INSTR un vēlākā pārbaude ar php (epxlode(',') utt)

 

dē) var sadomāt kaut ko ar SELECT ... REGEXP

 

droši vien vēl kādi citi varianti jābūt

[Gacha]

Man šķiet, ka visslabākais variants būtu selektam pievienot to BYNARY, jo tad ja meklēšu Jānis viņš man atgriezīs Jānis nevis Krišjānis, jo Krišjānis ir mazais j, ta būtu?

 

Tik nevaru atrast kā pareizi selekta jaraksta tas BINARY.

 

PS. Vai mysql manualis ir ari nokačajams, ja ne man zb, ka varu tik no 18:00 kaut ko atrast (visi proxy man ari ir nogriezti :( )