ugrás a tartalomhoz

Ékezetgondok MySQL-ben (+REGEXP)

pkadam · 2011. Júl. 12. (K), 02.16
Sziasztok!

Egy utf8_general_ci illesztésű táblában keresve a MySQL nem veszi figyelembe az ékezeteket, így a WHERE foo = 'bar' feltételre a "bár" szót is kiadja. (Kicsit tágabban: "weboldal = wéböldál".) Az utf8_hungarian_ci esetén kicsit szigorúbb, például az o-ö között így már különbséget tesz, de továbbra is: "weboldal = wéboldál". Az utf8_bin pedig túl szigorú, mivel ott a kis- és nagybetűk is eltérőnek számítanak ("weboldal != Weboldal").

A WHERE REGEXP '^valami$' megoldja a problémát, de kíváncsi vagyok, hogy létezik-e ennél elegánsabb megoldás – lehetőleg egy ideális karakterkódolási illesztés személyében. Nálatok mi erre a bevett gyakorlat? Milyen illesztést szoktatok használni magyar nyelvű adatokkal feltöltött táblákban?

--pkadam

Ui.: REGEXP barátunk persze szereti a tréfát, így bár nála a "weboldal"-t megtalálja a ^Weboldal$, viszont... az ^Állatkert$-re már nem jön ki az "állatkert". Hoppá. De továbbmegyek: az ^[á]llatkert$ sem adja ki az "állatkert"-et. Itt igen nagy gondok vannak, úgy érzem.
 
1

BINARY LOWER(foo) = 'bar'

Poetro · 2011. Júl. 12. (K), 02.39
BINARY LOWER(foo) = 'bar'
2

Köszönöm!

pkadam · 2011. Júl. 12. (K), 02.56
Köszönöm, tökéletes!

A REGEXP-es furcsaságra van ötleted? Tehát ^sz[a]lámi$-ra kijön a "szalámi" (nyilván), de ^szal[á]mi$-ra már nem, illetve: ^szAlámi$ megtalálja, de ^szalÁmi$ nem.
3

Osztályok

Poetro · 2011. Júl. 12. (K), 03.11
Szerintem az a helyzet, hogy a karakter osztályokat nem Unicode szövegként, hanem binárisan kezeli (ekkor a karaktert bájtokra szedi, és ezeket a bájtokat próbálja illeszteni). Sőt, az is lehet, hogy mindent binárisan kezel, majd azt illeszti case insensitive. Ezáltal történhet meg az hogy:
> SELECT "állatkert" REGEXP "^[á]llatkert$";
+--------------------------------------+
| "állatkert" REGEXP "^[á]llatkert$"   |
+--------------------------------------+
|                                    0 |
+--------------------------------------+
1 row in set (0.00 sec)

> SELECT "állatkert" REGEXP "^[á]+llatkert$";
+---------------------------------------+
| "állatkert" REGEXP "^[á]+llatkert$"   |
+---------------------------------------+
|                                     1 |
+---------------------------------------+
1 row in set (0.00 sec)
Ugyanakkor ha leveszem a ^-ot, akkor illeszkedik:
> SELECT "állatkert" REGEXP "[á]llatkert$";
+-------------------------------------+
| "állatkert" REGEXP "[á]llatkert$"   |
+-------------------------------------+
|                                   1 |
+-------------------------------------+
1 row in set (0.00 sec)
4

Ufff... Ez megint egy olyan

H.Z. v2 · 2011. Júl. 12. (K), 07.02
Ufff...
Ez megint egy olyan dolog, ami meg sem fordult a fejemben.
És fel is vetődött bennem rögtön egy kérdés: mit csináljon, aki case sensitive unique index-et szeretne?
Mert ugye elméletileg egyszerű a megoldás: collation=utf8_hungarian_cs.
Naja... csakhogy a show charset egyetlen _cs végűről sem tud, az utf8_bin pedig nem a magyar ABC szerint fog rendezni.


update:
Most találtam egy fórumon, hogy "There are no case sensitive utf8 collations in MySQL yet other than utf8_bin. "
Agyam eldobom...
Meg vele az összes eddigi terveimet is: magyar karakterkészletre egyáltalán nem találok case sensitive megoldást. :(
Komolyan kezdem visszasírni azt az időt, amikor még Oracle-lel dolgoztam...
5

Oracle

Poetro · 2011. Júl. 12. (K), 10.43
Ez is Oracle, csak kicsi sárga, de olcsó. Egyébként létezik más adatbázis-kezelő mint a MySQL, mint amilyen a PostgreSQL, Oracle, MS SQL, és használni is lehet őket PHP alól.
6

Igaz, de mióta eljöttem a

H.Z. v2 · 2011. Júl. 12. (K), 11.17
Igaz, de mióta eljöttem a munkahelyemről, még a megmaradt Oracle doksikat is kihajigáltam, így az már kiesett. (pedig végeredményben szerettem az Oracle-t - legalábbis üzemeltetői oldalról, de miután egy éven át nem találtam ilyen jellegű munkát...)

Viszont a varchar2 nem csinált ilyen hülye vicceket, hogy kisbetű-nagybetű nem számít, olyat meg pláne nem, hogy az "A"-t egyenlőnek tekintette volna az "á"-val. ;-)
(hm... nvarchar-t meg életemben nem használtam, lehet, hogy hiba volt? update: volt még egy elfekvő XE-m, kipróbáltam: egyik sem szolgál ilyen meglepetésekkel :-) )

Egy rövid pillantra felmerült bennem, hogy átpakolok mindent PostgreSQL-re, de a szokásos akadály: ingyenes tárhelyeken csak MySQL van és az olcsóbb fizetősök sem adnak mást sok esetben.