MySQL

Къде се изгуби бе човек, тука една седмица никакъв те няма. Може би на море?

Имах предвид 3,
но разлика в интерпретацията според мен няма в нито един от вариантите.
При BINARY всичко опира до т.н. ASCII таблица. Ако няма BINARY системата не е чувствителна към малки и главни букви в текущата кодова таблица.
Пример:
Имаме колона links със следните два реда: Проба, проба

SELECT * FROM `links` WHERE Name LIKE '%П%' Връща Проба проба

SELECT * FROM `links` WHERE BINARY Name LIKE '%П%' Връща Проба
SELECT * FROM `links` WHERE Name LIKE BINARY '%П%' Връща Проба
(Аз лично не знам каква е разликата между последните две. Има ли значение кое е BINARY, полето или критеря?)
Ако е зададено още при дефинирането на структурата на таблицата, не е необходимо да се указва в заявката. Винаги ще връща: Проба

Всичко разбира се опира до кодовата таблица която се използва, щото иначе как ще разбере от кой код да вади и каква стойност за да е нечувствително към разряда. Ето това имах предвид. Проблема не се свежда само до upper-case и lower-case.


Ето резултата от show variables like 'char%';

+----------------+--------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------------------------------------------+
| Variable_name | Value

|
+----------------+--------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------------------------------------------+
| character_set | latin1

|
| character_sets | latin1 big5 cp1251 cp1257 croat czech danish dec8 dos estonia
euc_kr gb2312 gbk german1 greek hebrew hp8 hungarian koi8_ru koi8_ukr latin2 la
tin5 swe7 usa7 win1250 win1251 win1251ukr ujis sjis tis620 |
+----------------+--------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------------------------------------------+
2 rows in set (0.01 sec)

__________________________________
Пътят към ада е осеян с добри намерения

Една седмица Пирин и една Созопол

Това, което се опитвам да ти подскажа е, че cp1251 е частен случай. И по едтна случайност като използваш latin1 UPPER('б') може и да ти върне 'Б' .... в зависимост от OS, опциите при компилиране, библиотеките, компилатора, линкера .... ама може и да не. В този клуб и особено във PHP има доста постинги по въпроса.

Всъщност всичко това дето го изкоментирахме много скоро ще ми се качи на главата в десеторно по-сложен вариант.

във 4.1 освен SERVER DEFAULT има
DATABASE DEFAULT CHARACTER SET
TABLE CHARACTER SET
CHARACTER SET за всяка колона поотделно

плюс CONVER(<expr> USING charset)

плюс COLLATE

и т.н.

отсега усещам какво ще се случи като почнат да валят питания ама що:

GROUP BY name COLLATE german1 така ... пък
... WHERE (name COLLATE latin1_de LIKE 'A' иначе и ...



Ето ти един много бърз тест в 4.1:

mysql> CREATE TABLE n (n1 char(12) character set latin1, n2 char(12) character s
et cp1251, n3 char(12) binary);
Query OK, 0 rows affected (0.01 sec)

mysql> show create table n;
...
| n | CREATE TABLE `n` (
`n1` char(12) character set latin1 default NULL,
`n2` char(12) character set cp1251 default NULL,
`n3` char(12) binary default NULL
) TYPE=MyISAM |

Забележи какво се случва със n3 като го дефинираш като BINARY. Остава без charset ... или по-точно наследява Default на таблицата ако има такъв или ако няма default на Базата ....

salle.online.bg/sig

Като ми дойдат до главата, ще ги мисля тия character-set-и. Иначе като идея ми харесва, но пък човек трябва да е по-внимателен.

Я кажи как стоят нещата със stored procedures. Четох, че щяло да има поддръжка "около" MySQL 5.0. Знаеш ли в коя версия ще ги има и кога ще излезе? Изобщо чувал ли си нещо по въпроса, нещо от кухнята?

__________________________________
Пътят към ада е осеян с добри намерения

е то аз съм във кухнята ....

Работи се по въпроса за SP т.е. има човек на който само това му е работата, но засега толкова.

За огромно мое съжаление sub-select са с много по-голям приоритет а сигурно знаеш колко много народ ги иска само заради заявки от рода на:

SELECT t1.id, (SELECT t2.b WHERE t2.ref = t1.id) FROM t1;

или

SELECT t1.id FROM t1 WHERE t1.id IN (SELECT t2.ref);


Иначе една новост във 4.0 (можещ да я пробваш), която съм сигурен, че ще се хареса особено на Web-developer-ите е комбинацията между () и LIMIT :)

Какво ще кажеш са следното (в 4.1 важи и за sub-selects):

mysql> (select * from n order by i limit 4) union (select * from n order by i desc limit 5) union (select * from n order by rand() limit 3) limit 10;
+------+
| i |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 9 |
| 8 |
| 7 |
| 6 |
| 5 |
+------+

salle.online.bg/sig