MySQL LIKE
Pi6a si az select * from table_name where col_name like 'A%'
i mi vra6ta rezultati zapo4va6ti osven s bukva 'a' i s drugi bukvi.

Bazata mi e na kirilitza, probvax da pi6a bukvata i na kirilitza i na latinitza, rezultata e ednakav.
I s drugi bukvi - sa6to

Ni6to ne razbiram, ne triabva da e taka

Mnogo 6te se radvam, ako niakoi moje da mi pomogne

Предиката LIKE на MySQL не е чувствителен към големи и малки букви.
Проблема се решава с оператора BINARY.

Съдържаниет е скрито
Влезте за да го видите

трябва да дълбаеш в настройките на операционната система и самия MySql....само, че къде точно идея нямам...
и аз бях забелязал преди време подобно нещо, ама реших че сам съм си виновен....
иначе отговора се съдържа във въпроса - MySql - нищо не плащаш нищо не получаваш...))

я опитай тая таблица да я сортираш по поле, в което има кирилица...тогава какво мазало става....

Мисля, че отговора на въпроса е точно това BINARY, затова дадох този линк.
Вярно е, че MySQL не е SQL Server още повече Oracle, но си има своите достойнства и не бива да се пренебрегва. Що се отнася до сортиране по поле в което има крилица, решението е пак BINARY(проблема е като горния).

Лек ден.

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

Moje bi triabva6e da spomena, 4e izpolzvam MySQL pod Windows98.
Osven tova malko se samniavam, 4e problema ima ne6to ob6to s malkite i golemite bukvi, no 6te probvam.

Blagodaria za saveta.

Drug problem, koito iznikna mejduvremenno - iskam da se izvedat samo zapisite, koito sa s max stoinost, a se izvejdat i ostanalite.

Редактирано от nevidimata на 27.08.02 12:44.

Ако "iskam da se izvedat samo zapisite, koito sa s max stoinost" означава, че искаш да изведеш N на брой записа като ги сортираш по големина в намаляващ ред:

SELECT * FROM mytable ORDER by myfield DESC LIMIT N;

Ако не съм те разбрал правилно, поясни се щото не си много ясен/ясна.

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

не съм 100% сигурен, че така ставаше, но може да погледнеш

Съдържаниет е скрито
Влезте за да го видите

Ami mai napisax -> select col_name1, max(col_name2) as max from table_name group by col_name1

Редактирано от nevidimata на 28.08.02 16:24.

когато напишеш WHERE pole1 LIKE '%A%' трябва да ти връща само резултати започващи с "А" или "а" не трябва да има резултати започващи с ДРУГИ БУКВИ.

никой никъде не се е оплаквал от малки и големи букви....

когато сортираш по колона, трябва да я сортира по АЗБУЧЕН ред, а не по случаен....обяснението с кодовата таблица, което даде някой преди мен е логично, и ако работи - добре....

Във файла my.ini се добавя:
[mysqld]
character-sets-dir=c:/mysql/share/charsets (тук се настройва спрямо вашата инсталация)
default-character-set = cp1251

Това е достатъчно за да работи сортирането на кирилицата без проблеми

Редактирано от Borko на 29.08.02 09:35.

смислен отговор!

предполагам не само сортирането а и филтрирането ще работи....

Страхотно! Това бачка!

Za sajalenie az ne moga da se poxvalia kato K - pri men tova ne6to xi4 ne ba4ka, t.e. izob6to ne promenia ne6tata

имаш някакъв много сериозен проблем. Принципно BINARY /*както каза Стан*/ винаги работи перфектно. Независимо windows или не, главните и малките букви имат различно аски представяне, сиреч различен двоичен код.
Или рещо бъркаш със заявката /*т.е. не достига до сървъра, както си я постнала*/ или просто базата ти не е в ред. Това не зависи от конфигурационния файл.
Откъде издаваш заявката, от клиентската програма mysql ли?

The things are always changing, I feel that it`s allright

Zaiavkata ia zadavam 4rez php i 4rez phpMyadmin i 4rez MySQL - vse edno i sa6to stava.

a napravi li si poleto BINARY vse pak? taka i ne kazva6? kakva e taq tvoqta misti4na baza danni. Ima6 li create izrazite, da probvame i nie?

дао дъ дзин

Ami opravix se ve4e, vsi4ko tragna.
S binary-to mai stana, iavno predi ne6to sam propusnala

Mnogo blagodaria na vsi4ki

Редактирано от nevidimata на 30.08.02 16:33.

Извинявам се за късното включване, но все пак проблема е изцяло в променливата character_set

mysql> show variables like 'char%';

Ще ти даде повече информация

BINARY просто прави сравненията Case-Sensitive

или на български казано при BINARY има разлика между главни и малки букви.
в контекста на текущия character-set


character_set влияе върху LIKE, ORDER BY, UPPER, LOWER
тъй, че погледни отново какво са ти отговорили phpGuru и Borko с две дребни добавки:

1. Като смениш character_set (а и всяка друга промелнива в my.cnf) трябва все пак да рестартираш mysqld

2. Задължително пусни myisamchk или REPAIR TABLE за всяка таблица която има индексирано поле на кирилица.

Съдържаниет е скрито
Влезте за да го видите

Виж сега salle,

1. В моя my.cnf не съм настройвал никакъв character-set и всичко що е кирилица работи. Работи сравняването, сортирането и т.н. Нямам никакви проблеми с това.

2. Що се отнася до BINARY, то мога да кажа, че може да се използва и за чувствителност към главни и малки букви, но основнвта му задача е да накара mysql-а да интерпретира отделните символи на стринговете бинарно. Чувствителността е следствие на това интерпретиране.

Вярно е, че в големите буквари пише само за това case-sensitivity, но това е така понеже повечето автори на книги не са се сблъсквали с кирилицата.

Не се съмнявам, че е полезно да се задава character-set, но до сега не ми е било нужно.

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

Дай да се разберем за какво говорим

1. name BINARY char(16) -> select ... order by name;
2. name char(16) -> select ... order by BINARY name;
3. name char(16) -> select ... where BINARY name = 'Гошо';
4. name char(16) -> select ... where name = BINARY 'Гошо';

Работата е там, че cp1251 е адски удобна кодова таблица от гледна точка на програмиране .... знаеш защо. Просто е подредена.

Не така стоят нещата с другите кодови таблици като latin2 и така нататък.

Заради пробата - пусни едно

mysql> show variables like 'char%'; и кажи какви кодови таблици имаш компилирани

Съдържаниет е скрито
Влезте за да го видите

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

Имах предвид 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 на Базата ....

Съдържаниет е скрито
Влезте за да го видите

Като ми дойдат до главата, ще ги мисля тия 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 |
+------+

Съдържаниет е скрито
Влезте за да го видите