Не пойму с поведением SQL

← →
DillerXX © (2009-08-23 03:52) [0]

Какое-то странное поведение.
CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=cp1251; INSERT INTO `test` (`id`) VALUES (11);

И теперь мы делаем следующий запрос: SELECT * FROM `test` WHERE `id` = "11aaaaaa"
Вы знаете, у меня он будет не пустым... не понимаю ничего, это как-то странно. Может у меня под виндой версия мускуля палёная?.. Может кто-нибудь у себя попробовать? Всё началось в того, что эта сволочь по запросу "11\"" находила какой-то результат, а дальнешие скрипты падали нафиг.
Спасибо.

← →
Inovet © (2009-08-23 10:57) [1]

Может с базой непорядок? Бэкап, рестор наверно есть в Мускл.

← →
sniknik © (2009-08-23 11:14) [2]

> CHARSET=cp1251
попробуй поменять на utf8, у mysql проблемы с кодировками, и бардак с ними в версиях и драйверах доступа.

← →
DillerXX © (2009-08-23 12:16) [3]

Нет... всё равно находит запись 11. Блин. Всех ненавижу. Столько времени на дебаг убил, чего только не перерыл с этими кавычками, а тут мускуль тупит.

← →
DillerXX © (2009-08-23 12:34) [4]

Поставил MySQL из Zend Framework, всё равно та же фигня.

← →
Anatoly Podgoretsky © (2009-08-23 12:56) [5]

> DillerXX (23.08.2009 12:34:04) [4]

Не тот SQL используй, вот и вся проблема.

← →
antonn © (2009-08-23 13:04) [6]

к числовому типу в запросе применяешь строку?

а вот так найдет?
SELECT * FROM `test` WHERE `id` = "22aaaaaa"

← →
sniknik © (2009-08-23 13:40) [7]

> к числовому типу в запросе применяешь строку?
ну и что? правильной реакцией была бы ошибка, а не "тихое" приведение типа очевидно нечислового.

← →
sniknik © (2009-08-23 14:28) [8]

кстати если в приведенном запросе int поменять на VarChar, все остальное не трогать, то любое обращение потом к таблице выдает
> EOleException : Поставщик данных или другая служба вернули состояние E_FAIL
это если через драйвер ODBC 5.1 подключаться, через 3й нормально...
в общем правильно его назвали - недобаза. :).

← →
antonn © (2009-08-23 14:32) [9]

или "недопровайдер" :)

для веба - само то. тока инструкции надо читать :)

← →
Anatoly Podgoretsky © (2009-08-23 14:43) [10]

> antonn (23.08.2009 14:32:09) [9]

Для Вебе есть другие не менее приемлемые СУБД - Firebird, PostGre, MSSQL

← →
antonn © (2009-08-23 14:46) [11]

ну лично мне мускла хватает, стоит на подавляющем большистве хостерских площадок. pgsql использова лишь пару раз, и то потому что заставили :)
хостинг с mssql уже дороже

← →
Anatoly Podgoretsky © (2009-08-23 14:50) [12]

> antonn (23.08.2009 14:46:11) [11]

А про Firebird почему молчишь?

← →
antonn © (2009-08-23 14:55) [13]

в вебе ни разу не сталкивался

← →
sniknik © (2009-08-23 16:46) [14]

> или "недопровайдер" :)
можно и так, но учитывая что оба и база и провайдеры "одних рук дело" это одно и тоже.

и кстати забыл в предыдущем посте указать, если ставить вместо cp1251 utf8 то уже оба провайдера более менее работают (не без "закидонов", есть вариант когда параметры не сходятся кодировкой с текстом запроса, но тем не менее без непонятых E_FAIL)
говорю же, бардак у них с этим делом... (или, если говорить "линукс-корректно", настраивается как угодно, зависит от кривизны рук. ;о))

← →
blackman © (2009-08-23 20:41) [15]

"11aaaaaa" - кавычки убери и оставь только 11. У тебя тип int.
В твоем случае преобразует только 11, aaaaaa - отбросит
В сущности, это твоя ошибка и в зависсимости от настроек мускула она может игнорироваться

← →
antonn © (2009-08-23 21:23) [16]

имхо если идет сравнивание с данными то кавычки лучше всегда ставить :)

← →
blackman © (2009-08-23 21:34) [17]

antonn © (23.08.09 21:23) [16]
C какого бодуна это лучше для int ?
Что бы было медленнее ? :)

← →
antonn © (2009-08-23 21:37) [18]

во-первых оно может выглядеть так, сравнить два поля
SELECT * FROM `test` WHERE `id` = value

во-вторых при отсутсвии такого поля оно выматерится :)

конечно тут число, и можно дополнительно фильтровать данные, а можно завести привычку экранировать именно данные и не париться :)

← →
blackman © (2009-08-23 21:46) [19]

antonn © (23.08.09 21:37) [18]
Выматерится не обязательно. Ежели в инете...Апач, PHP и Mysql, то возможно "мат" и подавляется.
Но, конечно дело привычки...

← →
DillerXX © (2009-08-24 01:29) [20]

Теперь буду фильтровать int поля вручную. Но вообще, это ни разу не правильно. SQL сервер не должен как-то вычленять численное начало из строки, а сразу возвращать нулевой результат.

Ещё одну вещь хочу узнать. Я правильно понимаю, что SELECT COUNT(*) ... и SELECT COUNT("") ... при любых раскладах работают за одинаковое время?

← →
antonn © (2009-08-24 01:39) [21]

вообще первый раз вижу count("") :)
в нем же перечисляешь названия столбцов

← →
Дмитрий С © (2009-08-24 09:28) [22]

> Ещё одну вещь хочу узнать. Я правильно понимаю, что SELECT
> COUNT(*) ... и SELECT COUNT("") ... при любых раскладах
> работают за одинаковое время?

Нет.
Mysql оптимизирует запросы вида SELECT COUNT(*) FROM `table`.
В случае SELECT COUNT("") FROM `table` - будет перебор и подсчет.

← →
sniknik © (2009-08-24 10:00) [23]

> а сразу возвращать нулевой результат.
нет, он должен возвращать ошибку о невозможности конвертации... или будут трудноуловимые логические баги, т.к. явная ошибка скрывается и подменяется на какой то результат.

> Mysql оптимизирует запросы вида SELECT COUNT(*) FROM `table`.
>
> В случае SELECT COUNT("") FROM `table` - будет перебор и
> подсчет.

Вот как... спасибо большое, буду знать.

Скажите, а во всё том же MySQL возможно ли присвоить полю значение по-умолчанию NOW() ? А то немного добивает в INSERT дописывать NOW() каждый раз.

вроде как нельзя.

Если в MySQL разрешено в качестве default-значений использовать функции - то можно.
Если не разрешено - нельзя.

> [23] sniknik © (24.08.09 10:00)

Тут дело даже не в трудноуловимых багах, а в том что, в стандарте четко определенно:
при сравнении строки и числа, строка приводится к числу.
Хотя у MySQL к стандартам отношение особое. За что нравится Firebird, один из основных принципов,
везде где только возможно следует стандарту.

> при сравнении строки и числа, строка приводится к числу.

приводить можно по-разному :)

SELECT 1 = "1aaaa"
вернёт 1
странно это как-то...

Вот ещё вопрос. Пусть в таблице 1млн записей. Как будет работать запрос

> SELECT `id` FROM `tbl` ORDER BY RAND() LIMIT 30

в постгресе и мускуле?

в мускле это выберет все записи в кеш, и оттуда выберет случайные 30. Вроде как :)
поэтому rand() одна из не рекомендуемых функций

← →
М. Береговой (2009-08-28 00:33) [33]

> DillerXX © (26.08.09 18:40) [30]
> SELECT 1 = "1aaaa"
> вернёт 1
> странно это как-то...

Мне кажется ничего странного нет... У вас тип данных объявлен как int(11), как числовой тип. А в ячейке находится строковое значение "1аааа", которое будет парсировано (как в javascript parseInt("1aaaa")->1) в числовой, что дает 1. Теперь выражение SELECT 1 = "1aaaa" будет преобразовано в SELECT 1 = 1, а поскольку 1=1 логическое, то результат будет типа bit (как в MS SQL), у которого только два значения 0 и 1. Поскольку 1=1 истино, то результат будет 1.

Есть такое мнение.

Не пойму с поведением SQL Найти похожие ветки