Рекомендованные сообщения

если это необходимо для конкретной задачи :-p

Что поделаешь, придется для каждой задачи все до ума доводить, чтобы машину не грузило:blink:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Такой вопрос не в темку , в чём смысл ODBC , зачем он нужен в MySql ? Что лучше всего использовать для связи PHP/MySql ?

Mysqli ? PDO ? Слышал также о SimpleDB :/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну в общем жду ответов )

Изменено пользователем GaLLe0n

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

GaLLe0n, подозреваю, что ты имел ввиду не SimpleDB, а DBSimple -_- а так, из родных средств - mysql (php4/5) или mysqli (php5).

из не родных могу порекомендовать http://php.ru/forum/viewtopic.php?t=6175 которая может использовать mysql, mysqli, pdo и что-угодно ещё (если написать драйвер).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

МММ , всё таки остановился на PDO +)

А что насчёт ODBC ? Зачем он нужен , не в курсе ?

А также , зачем нужны параметризованные запросы ( prepare() - execute() ) ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

0. зря, вещь весьма неудобная - нужно дорабатывать и дорабатывать.

1. в пхп особого смысла в нём нет, разве что приспичит поддерживать какую-то экзотическую бд..

2. http://ru.wikipedia.org/wiki/ODBC

3. для защиты от sql-инъекций

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подобью итоги и по-русски:

Если вы пишете кроссплатформенну CMS или еще какой продукт, который должен уметь работать с несколькими видами БД - вещь незаменима

В остальных случаях ее использования лучше избегать (тормозов меньше), недаром многие готовые двиги CMS'ок имеют время генерации страницы даже на мощных серверах >0.4 сек

 

Эти классы есть в каждом продукте, претендующем на звание готового крупного движка:tease:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
для защиты от sql-инъекций

Не только.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не только. Более того — и не столько. Покурили бы мануал, что ли..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Одно запрепаренное выражение может использоваться в дальнейшей работе скрипта сколько угодно раз:

 

$db->prepare($sqlstatement);

$db->execute;

...

$db->execute;

 

или еще конкретнее?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
$sql= $sqlstatement;
$db->query($sql);
...
$db->query($sql);

не вижу принципиальной разницы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Народ , такой вопрос .

Есть расширение php_pdo_mysql.dll в extension_dir

У меня не видно метода fetch , следовательно я решил найти полную версию pdo , а не встроенную .

Зашёл на pecl.php.net , скачал PDO , скачал mysql драйвер для PDO , но в том вопрос , как это установить ?

Везде написано , что нужно дллку запихать в extension_dir ,

но проблема в том , что в паке нет ниодного файла dll ..

Только .h , .c и .m4 , что делать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

GaLLe0n, если ты в линуксе, то пользуйся make

если винда - то не знаю, я обычно в таких случаях ищу откомпилированный dll модуль

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
не вижу принципиальной разницы.

Разница в скорости выполнения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Компилировать

 

Всё , понял . http://pecl4win.php.net/

Разница в скорости выполнения.

То есть параметризованные запросы быстрее ? И насчёт кавычек , почему двойные кавычки работают медленнее , чем одинарные ? ( на сколько я понял )

Изменено пользователем GaLLe0n

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При единичном использовании разница несущественна, при многократном — да, prepare + execute рулят. А если говорить про работу с конкретными СУБД, то иногда рулят еще больше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Разница в скорости выполнения.
да? где результаты тестов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да? где результаты тестов?

У мну в буке тоже так написано :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
где результаты тестов?

Результаты тестов — на сотнях высоконагруженных проектов. Вы уверены, что это я должен Вам что-то доказывать, а не наоборот? Похоже, в отличие от Вас, я все же читаю иногда мануалы и представляю общие принципы работы СУБД.

 

Ну да ладно, для тех, кому интересно, поясню почему prepare + execute лучше (кстати, в описании модуля PDO горячо любимого Вами PHP тоже указывается, что для многократного выполнения лучше использовать связку, а не query).

 

Итак, в нормальных СУБД механизм выполнения запроса (упрощённо, конечно) выглядит так:

1. СУБД разбирает запрос на составляющие для определения с какими таблицами, вьюхами итп будет работать.

2. С помощью встроенного оптимизатора определяет в каком порядке будет обращаться к этим таблицам на основе данных из WHERE (для простых insert этот пункт необязателен, для сложных — тоже важен), директив оптимизатору итп.

3. Определяет какие поля нужно вернуть в результате выполнения запроса.

4. Помещает разобранный запрос в кэш. Это делается для того, чтоб при следующем таком же запросе не тратить ресурсы на пункты 1-3.

5. Выполняет запрос — читает нужные файлы индексов, данных итп.

 

что происходит в случае prepare + execute

 

в СУБД поступает запрос вида

SELECT field1 FROM table1 WHERE id=:a

он разбирается один раз, помещается в кэш и дальше СУБД просто делает нужные выборки на основе бинденной переменной :a

 

что же происходит в случае query()

в СУБД поступают запросы вида

SELECT field1 FROM table1 WHERE id=1;

SELECT field1 FROM table1 WHERE id=2;

..

SELECT field1 FROM table1 WHERE id=1000;

 

в каждом из этих случаев СУБД будет выполнять все шаги, описанные выше: разбор, кэширование итп. То есть, на лицо чрезмерное расходование ресурсов. Для маленьких проектов это не очень критично, для больших — существенное снижение быстродействия.

 

Итак, выводы:

кэширование запросов сервером с помощью prepare + execute позволяет СУБД не делать повторно полный разбор выражения, а выбрать уже полученный ранее результат разбора из кэша. Если же формировать запросы с константами, то они мало того что будут проходить все этапы разбора, так еще и будут «выталкивать» из кэша другие часто выполняемые запросы, снижая производительность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
что же происходит в случае query()

в СУБД поступают запросы вида

SELECT field1 FROM table1 WHERE id=1;

SELECT field1 FROM table1 WHERE id=2;

..

SELECT field1 FROM table1 WHERE id=1000;

SELECT field1 FROM table1 WHERE id BETWEEN 1 AND 2

жду реальных примеров, на которых использование prepare было бы сколь-нибудь существенно быстрее, а не сферических запросов в вакууме.

 

кэширование запросов сервером с помощью prepare + execute позволяет СУБД не делать повторно полный разбор выражения, а выбрать уже полученный ранее результат разбора из кэша.
ага, а выборка из кэша - прям-таки мгновенная операция? в любом случае разница если и есть - на уровне двойных и одинарных кавычек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
жду реальных примеров

Дарк-Демон, если вы не понимаете, что

а + b + c + d

работает медленнее, чем просто

d

то, боюсь, ниасилите и менее "сферическо-вакуумных запросов".

 

Ваш пример с between — это лажа. Я привел не пример выборки в одном запросе 1000 строк, а скорее пример выборки в 1000 параллельных сессиях одной строки. Представьте, что есть сайт с тысячью статьями, к каждой из которых в данную минуту подключается по пользователю. Поймете, что я имею ввиду.

 

а выборка из кэша - прям-таки мгновенная операция?

Выборка плана из кэша — очень быстрая операция, не требующая дополнительных накладных ресурсов CPU в виде разбора SQL. Вы, наверное, удивитесь, но максимальное число операций, производимых CPU ежесекундно, — конечно.

 

И так, для интереса — с какими максимальными нагрузками Вы сталкивались? Скажем, в хитах в час? Подозреваю, что Вам действительно может быть не очень понятно, о чем я пытаюсь Вам рассказать. На маленьких нагрузках все изложенное не очень существенно.

Изменено пользователем Байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Дарк-Демон, если вы не понимаете, что

а + b + c + d

работает медленнее, чем просто

d

то, боюсь, ниасилите и менее "сферическо-вакуумных запросов".

 

Ваш пример с between — это лажа.

пример с between - это тот самый d.

это, конечно, оригинально - обвинить меня в своих тараканах, на которых я только что показал пальцем ;)

 

Я привел не пример выборки в одном запросе 1000 строк, а скорее пример выборки в 1000 параллельных сессиях одной строки. Представьте, что есть сайт с тысячью статьями, к каждой из которых в данную минуту подключается по пользователю. Поймете, что я имею ввиду.
о великий гуру, подскажи мне убогому, как расшарить коннект к бд, чтобы выполнить prepare() только в одной сессии, а execute() во всех? ^__^

 

И так, для интереса — с какими максимальными нагрузками Вы сталкивались? Скажем, в хитах в час? Подозреваю, что Вам действительно может быть не очень понятно, о чем я пытаюсь Вам рассказать. На маленьких нагрузках все изложенное не очень существенно.
о, будем меряться пиписьками? ;) ну, я сталкивался с такими нагрузками, когда СУБД перестают рулить и начинают рулить старые добрые файлы. Изменено пользователем Dark-Demon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
ну, я сталкивался с такими нагрузками, когда СУБД перестают рулить и начинают рулить старые добрые файлы.

Это типа 1 хит в час?:)

 

это, конечно, оригинально - обвинить меня в своих тараканах, на которых я только что показал пальцем happy.gif

Я все-таки полагаю байт тщетно пытается объяснить, что при огромном числе обращений к базе, гораздо быстрее препарировать запросы, дабы не тратить время на разборку самого запроса.

жду реальных примеров

на пальцах:

$a=array(....);

for($i=0;$i<count($a);$i++){

...

}

или так

$a=array(....);

$len=count($a);

for($i=0;$i<$len;$i++){

...

}

Что быстрее? Если цикл небольшой (2-3 раза) то разницы вообще нет. А попробуйте запустить цикл несколько тысяч раз, посмотрим что будет:)

 

Кстати кеш работает порой в сотни раз быстрее, я думаю, логичнее, когда в базу делается 1 кешированный запрос, нежели десяток обычных...

Изменено пользователем RPG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
пример с between - это тот самый d.

Нет, это не d.

Под буквами я имел ввиду этапы выполнения запроса СУБД. См. выше.

 

как расшарить коннект к бд, чтобы выполнить prepare() только в одной сессии, а execute() во всех

Блин, видимо, я плохо объясняю :lol:

Еще раз — после первого выполнения prepare + execute в одной данной сессии, запрос попадет в кэш СУБД и в последующих сессиях уже не будет тратиться CPU на разбор этого запроса. Зачем, если его уже разобрали ранее? В случае использования query, разбор будет происходить для каждого нового запроса.

 

Совсем уж простая аналогия:

Представьте, что вы пришли с друзьями в ресторан и пообещали угостить их классным пивом. Когда приходит официант, Вы говорите "всем по кружке Вельвета" и официант тут же уходит выполнять заказ.

 

Вторая ситуация:

в ресторан приходит несколько человек, пока еще не знающих что же заказать. К каждому из них подойдет официант, предложит меню и будет ждать заказа. Согласитесь, это медленне, чем в первом случае — ведь клиентам сначала нужно изучить меню, понять чего хочется, дождаться официанта за заказом итп.

 

Понятно, надеюсь?

 

Ради интереса все же провел ряд тестов на prepare + execute и query для различных языков и СУБД. Завтра-послезавтра постараюсь оформить в статью, выложить у себя в блоге и дать здесь ссылку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Это типа 1 хит в час?
наоборот <_<

 

Я все-таки полагаю байт тщетно пытается объяснить, что при огромном числе обращений к базе, гораздо быстрее препарировать запросы, дабы не тратить время на разборку самого запроса.
а я тщетно пытаюсь объяснить, что накладные расходы от добавления одного лишнего запроса к субд (prepare) и использования кэша - запросто нивелируют все преимущества prepare. если не полностью, то хотябы в той степени, когда разница не существена.

демагогией тут ничего не выяснить. только тестирование может поставить точку в этом споре.

 

Что быстрее? Если цикл небольшой (2-3 раза) то разницы вообще нет. А попробуйте запустить цикл несколько тысяч раз, посмотрим что будет
теперь и ты о сферических конях...

 

Еще раз — после первого выполнения prepare + execute в одной данной сессии, запрос попадет в кэш СУБД и в последующих сессиях уже не будет тратиться CPU на разбор этого запроса.
ага, и кэш этот - таблица с полем типа "текст" и поиск ведётся по полному совпадению строки. чем больше кэш и размеры строк - тем медленнее поиск. чем меньше - тем выше вероятность, что нужного значения в кэше не останется (или у нас один единственный запрос на всю сессию?)

 

Совсем уж простая аналогия:

Представьте, что вы пришли с друзьями в ресторан и пообещали угостить их классным пивом. Когда приходит официант, Вы говорите "всем по кружке Вельвета" и официант тут же уходит выполнять заказ.

Нет, не так. А так:

- возьмите, пожалуйста, блокнот - у нас большой заказ

[официант удаляется и возвращается с блокнотом]

- так, принесите мне вина

[официант уходит, попути записывая заказ, и возвращается с бутылкой вина, которую на глазах распаковывает и наливает вино в бокал]

- а моей подруге - мартини

[то же самое, но с мартини]

 

Вторая ситуация:

в ресторан приходит несколько человек, пока еще не знающих что же заказать. К каждому из них подойдет официант, предложит меню и будет ждать заказа. Согласитесь, это медленне, чем в первом случае — ведь клиентам сначала нужно изучить меню, понять чего хочется, дождаться официанта за заказом итп.

Опять же - не так. А так:

- принесите мне вина

[официант уходит, у стойки берёт блокнот и записывает "вино - 1шт", оставляет блокнот, берёт вино возвращается и наливает в бокал]

- а моей подруге - мартини

[то же самое, но с мартини]

 

итого: у тебя 3 запроса, а у меня - 2. если дб-сервер выделенный (кто говорил о больших нагрузках?), то это очень даже существенно. а если учесть, что prepare по твоей логике нужно выполнять в каждой сессии, перед каждым отличающимся запросом - вообще кранты.

 

Ради интереса все же провел ряд тестов на prepare + execute и query для различных языков и СУБД. Завтра-послезавтра постараюсь оформить в статью, выложить у себя в блоге и дать здесь ссылку.
во, за это заранее, спасибо ;) хорошая пища для критики... ^__^ Изменено пользователем Dark-Demon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну, собственно, как я и подозревал - для препаров кэш попросту не работает...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас