← Uz sākumu

Kā iekš MySQL sakārtot latviešu burtus pareizā secībā

2010. gada 28. oktobrī, 22 komentāri

Atzīšos, ka negaidīju. No sākuma vairākus gadus kā jau latvieši parastie - cietāmies, ka iekš MySQL nevar pareizi sakārtot rindas, kas ir ar mūsu burteļiem. T.i. - kārtojās pareizi, bet ne patskaņi.

Aizvakar beidzot izlēmu paziņot par bugu. Tas plūdeni tika pārvērsts feature requestā. Un beigu beigās kāds ielika arī pagaidu workaroundu.

SELECT * FROM `ctest` ORDER BY `keyword`, BINARY keyword;

Tiesa, MySQL kontekstā pēdējās nedēļas mani vairāk kaitina tā ierobežojumi un sintakses īpatnības, kuras parādās, kad ir vēlme uzrakstīt SQL skriptu, kurš izmanto kursorus, kad ir vēlme uzrakstīt storēto procedūru vai funkciju un tā kļūst neganti lēna, jo ceļā stājas kolācijas, utt. Tā kā kārtošana ir pats mazumiņš. Bet, nu, patīkami :)

Papildināts pēc testiem. Darbojas tikai uz neutf8 kodējumu dēļ mainīgā baitu daudzuma, kas atvēlēts burtam. Kā arī jāņem vērā, ka šāda kārtošana neņem vērā indeksus otrajam kārtošanas nosacījumam.

Papildināts pēc vēl pāris testiem un sarunām #php.lv. Te gan jāpieņem, ka visur ir pareizi norādīti čārseti :)

SELECT keyword FROM ctest ORDER BY CONVERT(keyword USING ucs2) COLLATE ucs2_latvian_ci, CONVERT(keyword USING ucs2) COLLATE ucs2_bin ASC;

Papildināts pēc rūpīgākas pārbaudes. Ne sūda. Rekursīvi atduramies pret to pašu problēmu. Ienāca prātā variants ar trigeri, papildus lauku un 'glāžšķūņu rūķīšu' pārveide par 'g1l1a2z2s2k2u2n2u1 1r1u2k2i2s2i1' :)

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar Mārtiņš

2010. gada 28. oktobrī, plkst. 15:59

Negribas jau troļļot, bet nu vai nav vieglāk izvēlēties citu RDBVS? :)

Gravatar laacz Autors

2010. gada 28. oktobrī, plkst. 16:08

Mārtiņš, nav gan :)

Gravatar Grrr

2010. gada 28. oktobrī, plkst. 17:10

Nav, nav. Pieradumam liels spēks.

Gravatar j

2010. gada 28. oktobrī, plkst. 17:28

pēdējais selects konvertē visus rowus, lai varētu izpildīt order by..

Gravatar archaic

2010. gada 29. oktobrī, plkst. 04:08

Problēma veca kā zeķe. Mēs ar neko labāku neatradām, kā kārtošanai taisīt speciālus laukus. Kā sendienās. Ir lauks. Un ir lauks_sort.

Gravatar Mārtiņš

2010. gada 29. oktobrī, plkst. 11:13

PostgreSQL: The world's most advanced open source database :-)

Varēsi arī iemēģināt PostGIS savai Ipiķu problēmai.

Gravatar laacz Autors

2010. gada 29. oktobrī, plkst. 11:44

Mārtiņ, PostgreSQL kolāciju un internacionalizācijas jautājums nav tik vienkāršs. Ir ļoti daudz dažādu ierobežojumu, kurus vismaz sākontnēji man nav izdevies apiet.

Kas attiecas uz Ipiķu problēmu - sen jau atrisināta. Izmantoju Shapely un python. Attiecīgajām funkcijām nav nepieciešams visu turēt datubāzē un veikt manipulācijas tur.

Gravatar Grrr

2010. gada 29. oktobrī, plkst. 12:07

Varbūt uzraksti, ja sanāk, par postgresa ierobežojumiem, lūdzu. Varētu būt noderīgi saprast, ja nākas izvērtēt iespēju lietot PG kādā projektā.

Gravatar laacz Autors

2010. gada 29. oktobrī, plkst. 12:14

Grr, es neesmu speciālists postgresa jautājumā, raču i18n mysqlā ir augstākā līmenī, ja neskaita konkrēto problēmu ar sekundāro kollāciju.

Gravatar asdf

2010. gada 29. oktobrī, plkst. 13:51

To jau sapratām, ka neesi speciālists RDBVS jautājumā.. Tāpēc arī interesē kas ir tie "ļoti daudzie dažādie ierobežojumi, kurus tev nav izdevies apiet" PostgreSQL gadījumā :)

Gravatar Kirurgs

2010. gada 29. oktobrī, plkst. 14:59

Sort ta gan ir problema :) mysqla :) alter session set nls_language=latvian ? :D

Gravatar laacz Autors

2010. gada 29. oktobrī, plkst. 15:15

Kirurgs: tas nav orākliski? :)

Gravatar mareks

2010. gada 30. oktobrī, plkst. 11:05

pg kolācija un i18n ir ''tieši proporcionāli" saistīta ar os uz kura tā darbojas i18n īpašībām un iespējām, i.e. ja os-am ir problēma ar latviešu burtu kārtošanu, tad arī pg būs tieši tādas pašas problēmas. snoracle pabērnam šis ir, afaik, citādi. ja ir interese, varu padalīties ar "korektiem" localedef objektiem, kuri savulaik vēl tika rakstīti tādam mazpazīstamam os-am kā sunos 5.6

Gravatar Feldmans

2014. gada 6. martā, plkst. 02:19

   <!-- Case equivalences -->
  Aa <!--  A/ a -->
  Āā <!-- -A/-a -->
  Ee <!--  E/ e -->
  Ēē <!-- -E/-e -->
  Ii <!--  I/ i -->
  Īī <!-- -I/-i -->
  Oo <!--  O/ o -->
  Ōō <!-- -O/-o -->
  Uu <!--  U/ u -->
  Ūū <!-- -U/-u -->
   <!-- Letter orders -->
  aā <!-- a before -a -->
  AĀ <!-- A before -A -->
  eē <!-- e before -e -->
  EĒ <!-- E before -E -->
  iī <!-- i before -i -->
  IĪ <!-- I before -I -->
  oō <!-- o before -o -->
  OŌ <!-- O before -O -->
  uū <!-- u before -u -->
  UŪ <!-- U before -u -->

Gravatar Feldmans

2014. gada 6. martā, plkst. 02:20

Hmm. Respektīvi - šis man strādā

http://pastebin.com/vNzNEbgt

Gravatar Andris

2021. gada 17. martā, plkst. 21:34

Kā piemērā minētos Collation datus padot datubāzei?

Gravatar Arnis

2017. gada 10. oktobrī, plkst. 19:21

Ir kādi jaunumi attiecībā uz šo?

Man, piemēram, savjadzējās, vienā tabulā glabāt 3 valodu tekstus, bet atlasīt tos pareizajā alfabēta secībā, atkarībā no atlasāmās valodas. Varbūt jaunākajās MySQL versijās ir kāds jaunums šajā sakarā? Tajā bug requestā nekas nav mainījies pa šo laiku https://bugs.mysql.com/bug.php?id=57731

Gravatar Arnis

2018. gada 19. janvārī, plkst. 00:41

Nu re kā - nepagāja ne 8 gadi, kad IR FIX! https://bugs.mysql.com/57731 Būs iekļauts 8tajā versijā.

Interesanti ... kur palikušas 6-tā un 7-tā? (7-tā īstenībā eksistē - Github relīzēs ir 2x septītās, bet kas viņu zin, kāpēc tā https://github.com/mysql/mysql-server/releases

Nu nekas - vismaz 8-tajā jābūt pareizam sortam!

Gravatar Andris

2021. gada 17. martā, plkst. 21:32

No Arņa Juraga komentāra (2019. gada jūnijā) MySQL kļūdu izsekotājā (kļūda 57731) izskatās, ka kārtošana, joprojām, notiek nepareizi. Vai ir atrasta aktuāla metode kā panākt pareizu kārtošanu MySQL?