IMHO tā utf8 meklēšana joprojām nedaudz gļuko aptuveni 10% gadījumu (ne šajā lapā, bet citur). Vienkārši rāda, ka nav atrastu ierakstu, kaut gan DB tādi ir.

Arnolds, ko nozīmē "ģluko"?

SELECT * FROM paakji_table WHERE name LIKE '%glazsk%';

neatrod neko.

SELECT * FROM paakji_table WHERE name LIKE '%glāžšķ%';

atrod Glāžšķūni.

Arnolds, kāda ir tabulu un lauku kollācija? Kādi konekcijas, servera un visi pārējie čārseti? Visticamākais, ka ir neatblistība to starpā, kas arī liedz izmantot šo fīču :)

Un gan tabula, gan kolonna ir utf8_latvian_ci kodējumā.

Arnold, ar to vēl nepietiek. Ir visādi servera, datubāzes, konekcijas čārseti.

Rakstiņš taisni laikā, lai gan nedaudz nokavējies. Ar UTF-8 mūžīgās bēdas ar kollācijām, kad lapa visu saprot, bet myadmins ar savu kollāciju (un liec kādu gribi) visu sačakarē, eksportēt ar mysqldump arī nevar un pielabot myadminu nesanāca, lai tas neliktu savu kollāciju. Nu vismaz ar MySQL 5 šādi gļuki.

Hmmz, ar utf8_general_ci tipo meklē ok (iekš HTML utf-8). Vienīgi paliek "ķāķišķi" == "kakiski', bet tas manos gadījumos parasti ir feature nevis bug :)

Kārli, tas tā notiek pat tad, ja kverijus noseivo teksta failā utf-8 kodējumā un tad peisto iekšā myadminā?

set names utf8 Izveido divas konekcijas (iekš php, perl) vienu ar latin1 un otru ar utf8. Viens loops kas izskrien cauri ar latin1 un updeito caur utf8. Rezultāts gan jaut tas pats būs :) Bet nu bija baigais prieks, ka sāka strādāt ORDER By un LIKE, he-he Tā, kā ģeniālās idejas rodas kad uz kastes griežas pārītis strādājošu projectu, tad apzvērējos brūvējot jaunu servaku iekš my.conf ierakstīt default konekcija - uttf8. Nuuu.. ja neaizmirsīšu.

driikst tev pajautaat, kaapeec izmanto MySQL? mees te ar PostgreSQL njemamies un nav nekaadu probleemu ar encodingu (UTF8 webam un UTF8 datubaazei), ar aatrdarbiibu (tabulaa ar gandriiz 100k ierakstiem search, pagging un viss paareejais aiznjem ljoti maz laika) un ar paareejaam fiichaam. pietam proceduuras, triggeri un visas paareejaas postgre fiichas ir kaa medusmaize saliidzinot ar to, ja viss buutu jaadara ieksh php un datubaazee ietu tikai select insert update un delete funkcijas..

Pēc visādiem mēģinājumiem situācija nav radikāli mainījusies: ir datubāze, kuru myadmins rāda normāli, un ir tāda, kuru nerāda normāli (attiecīgi tāds pats arī datu eksports). Tabulām visu rāda ok. Tātad atšķirība būs pie konekcijas ar kuru dati ievadīti? Kā viņas "vienādot"?

imho phpmyadmin'am nav korekti pastāstīts, lai lieto utf-8. Pats gan savu mūžu neesmu lietojis phpmyadmin, pilnīgi pieticis ar komandrindas tūļiem.

ņā, mēs te, gēki, sēžam uz pgsql. jā laacz, ko tu kaukādu tur mysql. pats par sevi ar` brīnos.

100k ieraksti, o-bā....

nah to mysql. direktōr! man pietiek!

1. kas vainas myskl? Tagad taču mysklis arī supportē procedūras viewus un ko tik visu vēl ne. Pats gan neesmu mēģinājis neko no tā dzīvē izmantot.

2. man ar bija problēma ar meklēšanu ierakstiem, kas utf-8 kodējumā. Ja izkārtojums ir "utf8_latvian_ci", pie meklēšanas mēdza neatgriezt visus ierakstus... Teiksim, "aaa" un "āāā" gadījumā atrada tikai pirmo no abiem ierakstiem. Nomainot uz "utf8_bin" no problemos.

3. Tabula ar 100k ierakstiem -- aaaahahahaa, kas tad tur īpašs? Esmu drošs, ka te dažs var nosaukt krietni lielākus ciparus. :) Man, piemēram, db uz kādiem 15mio ierakstiem.

sn : 100k ieraksti nav nekas (nav rādītājs) .. manuprāt uz sqlite ar funciklierētu zvērā ..

Kas attiecas uz procedūrām un trigeriem tas ir koks ar trīs galiem - proti simple SQL kverijus tomēr vieglāk "monitorēt" un saprast kas kur kādā brīdi lockojas vai bremzē.. Palaižas tur kaut kāda procedūra / events uz DB loopā vai hvz ar kādu izpildes mehānismu un ej nu zīlē kapēc DB ir saliecies līdz nemaņai ar kaut kādiem deadlockiem.. proti no debug viedokļa jākne lielāka (par priekšrocībām šoreiz nerunāsim).

Attiecībā uz characteriem mēs pie MySQL startēšanas pieliekam --skip-character-set-client-handshake un iztiekam bez visiem SET NAMES u.c. kverijiem pēc konekcijas izveides (t.i. serveris ignorē php clienta standarta latin charsetu un izmanto savu utf8))

Es zināju, ka MySQL der tikai mazām bāzītēm un nenopietniem uzdevumiem, bet nu ka tik slikts ... Vai, varbūt, tās datu bāzes un aplikācijas ir tik slikti uztaisītas, ka spētu pazemot jebkuru DBVS ?

Kāpēc mazām?! .. diezgan lieli apjomi tiek dzenāti pie samērā augstām noslodzēm/jaudām. Viegli implementēt, samērā viegli uzturēt .. var iztikt bez liekām izmaksām. Ir savi "caveati" (nianses) bet nu ..

Jo ja runa iet par технологиām tad DB tā tiešajā nozīmē nav nekāds "meklētājs" .. tam ir citi pļurzuļi jāveido un dati jaindeksē savādāk.

Nezinu kaa ir ar MySQL, bet ar PostgreSQL var vienkaarshi pie izsaukshanas uzlikt UTF-8 to LATIN 7 un tev rezultaati jau ir bez ā,č,ž utt ..

Pirms tam veel tikai search jaanonjem nost visi ā,č,ž .. un buus tev tas pats rezultaats.

Meklējot "glāžšķūņi" atradiisim gan "glāžšķūņi", gan "glazskuni", gan "gļĀzSķunī", gan ...

Nu mazām tādēļ, ka no normālas DBVS es problēmas negaidu agrāk kā pie 100 miljoniem ierakstu, nevis 100k ...

Laacz, vai tu man varētu palīdzēt? Problēma tāda, ka nevar atrast ierakstu, ja meklē 'janis', pat 'jānis'. Atrod tikai tad, kad meklē 'Jānis' (tiešā sakritība). No MySQL daudz nezinu, tāpēc jautāju: vai ir jābūt kaut kam pieprasījumā iekšā, lai atrastu 'Jānis', neskatoties uz to, vai ir vai nav latviešu rakstzīmes, lielie un mazie burti?

Un kādēļ jālieto BLOB, nevis TEXT?

Oki do! Ja vēlamies izmantot utf8, tad turpinam izmantot TEXT, jo tad nav jāuztraucās par lielajiem un mazajiem burtiem. Uzstādām datubāzes izkārtojumu uz 'utf8'. Un uzreiz pēc 'mysql_connect()' liekam 'mysql_query("SET NAMES utf8");' Un viss strādā! :) Next time, lūdzu, daudz izsmeļošāk, dārgais Laacz! Tu mums ļoti palīdzi, taču mums ir grūti, ja nepalīdzi līdz galam... :*

Ar mysql nav nekādu problēmu mums online bāze 6GB, visi čarseti strādā perfekti.

Esmu pamaniijis LV taadu shaizi ka daudzi tautieshi nodefinee lauku kā utf8 bet mochii iekshaa latin1 vai kautko citu - tikai ne utf8... un protams tad saakas probleemas ar mekleeshanu kaartoshanu uttt.

PostgrSQL ir daudz leenaaks, esam testējushi. Tā arii neatradu kā online tabulas iepūst atmiņā. Mūsu gadījumā vdazhas tabulas, lielākā no kurām ir 4GB stāv pilnībā atmiņā un strādā tā itkā tajā būtu tikai 1000 ieraksti.

Es nesaku ka mySQL ir labāks, vienkārši katrai bāzei sava niša.

Laacz, pielabo lūdzu to kveriju, kurš ir paragrāfā par 'nullveidīgajiem baitiņiem'. Kaut kādā brīdī tur ' vietā parādījušies '''.