[ casiel @ 09.04.2010. 15:15 ] @
Mozda ce se neki profi DB nasmejati meni, ali i ja sam se nasmejao na OVO...

U tabeli sa 3 kolone, nalaze se podaci:

Language --------Key ----------- Translation
EN ------------- sale ----------- Sale
EN ------------- SALE ----------- Sale

(da ne ulazimo u problematiku zasto postoji prevod sa engleskog na engleski: u tabeli se nalaze prevodi za 7 jezika i engleski pride kao default).

Kada izvrsim upit

SELECT key FROM translation
where key = 'sale' (ili 'SALE', svejedno)
and language='EN';

dobijem oba sloga.
Ne mogu da kazem da sam to ocekivao, ali razmisljam...
'Hajde da ne cipdlacim, key = 'sale' iz nekog razloga nije case sensitive, mada ne znam zasto, ali guglovacu malo, pa cu saznati'

Sledece 'iznenadjenje' necu razumeti ni uz pomoc gugla

SELECT distinct (key)
FROM translation
where key = 'SALE'
and language = 'EN';

Ovaj upit vraca jedan slog:

Language Key Translation
EN sale Sale

Ovde sam poceo naglas da se smejem.
Rezultat je prva od dve vrednosti i nema veze sa onim sto sam ocekivao da vidim od SELECT DISTINCT.
Nisam bio lenj, pa sam se poigrao. Ovo prethodno nije najgore sto je moglo da mi se desi.
Nagradno pitanje: (bez izvrsavanja upita, molim)

Koliko slogova vraca sledeci upit:

SELECT distinct (key) FROM translation
where ucase(key)=lcase('sale')
and language='EN';

Ja bih rekao 0 (nula) na nevidjeno i svadjao bih se do krvi sa bilo kim ko tvrdi suprotno.
Podignem key u uppercase i poredim ga sa necim sto je vec lowercase, ali za svaki slucaj uradim to jos jednom, ko pandur se 2 otkucane karte u prevozu.
Te dve vrednosti nece biti iste za dve zivota.

Na zalost, pogresio bih. Rezultat upita je 'sale'.

Moja draga baza je MySQL 5.0.88-community-nt, tabela translation je MyISAM.

Nadam se da nisam bio nejasan.
I da jos pojasnim, ja sam problem koji sam imao resio.
S obzirom da se ova app koristi jednom u par meseci, tabelica ima 5600 slogova, nisam morao da brinem o performansama:
stavio sam 'binary' ispred key i vrednosti koju sam poredio, i sve je proradilo.

Gugl (odnosno http://dev.mysql.com/doc/) jos nije dao ni ideju zasto SELECT DISTINCT ovako radi.
Jos uvek trazim.
[ bogdan.kecman @ 09.04.2010. 15:29 ] @
objasnjenje u jednoj reci - kolacije

u vise reci poredjenje stringova se vrsi preko kolacija a vecina kolacija ujednacava mala i velika slova kao i slova sa kvacicama i slova bez kvacica, postoje cak i kolacije koje ujednacavaju cirilicu i latinicu (mislim da ne dolaze uz mysql) ... tako da je C == c == č == ć == ...

ako zelis da imas "case sensitive" poredjenje i da c != č != ć onda moras da koristis binarnu kolaciju (to su one kolacije koje imaju _bin nastavak u imenu)

kod mysql-a ne mozes da mesas kolacije real time tako da se ako ne navedes, koristi kolacija iz kolone ali mozes da navedes drugu kolaciju u upitu

dakle

Code:

mysql> select 'a' = 'A';
+-----------+
| 'a' = 'A' |
+-----------+
|         1 |
+-----------+
1 row in set (0.00 sec)

mysql> select 'a' = 'A' collate latin1_bin;
+------------------------------+
| 'a' = 'A' collate latin1_bin |
+------------------------------+
|                            0 |
+------------------------------+
1 row in set (0.00 sec)
[ bogdan.kecman @ 09.04.2010. 15:32 ] @
a sto se tice dokumentacije - pocni odavde: http://dev.mysql.com/doc/refman/5.1/en/charset.html
[ casiel @ 09.04.2010. 15:35 ] @
Amin :)

I veliko hvala :).