Comments 165
Если честно, я не думаю, что много кто пользуется mysql и mysqli. Как минимум PDO, как максимум — более развитый DBAL.
mysql — самый часто используемый модуль php, об этом говорят сами разработчики php.
И это создает большие проблемы. Разработчики и рады бы выкинуть это «небезопасное старье», но из-за популярности модуля не могут этого сделать сразу. Поэтому запланированы несколько этапов по «отучению» пользователей от mysql модуля. Первый из них — повсеместные рекомендации в документации с призывом использовать mysqli или PDO. Например тут.
PDO выигрывает у mysqli только возможностью, как сказано в данной статье, относительно быстрой и легкой смены БД в проекте.
И это создает большие проблемы. Разработчики и рады бы выкинуть это «небезопасное старье», но из-за популярности модуля не могут этого сделать сразу. Поэтому запланированы несколько этапов по «отучению» пользователей от mysql модуля. Первый из них — повсеместные рекомендации в документации с призывом использовать mysqli или PDO. Например тут.
PDO выигрывает у mysqli только возможностью, как сказано в данной статье, относительно быстрой и легкой смены БД в проекте.
Очень странно. Я бы по доброй воле ни за что не стал использовать mysql.
Почему?
Я имел ввиду не БД, а mysql_* функции PHP.
Во времена php3 это был единственный путь. С тех пор и повелось.
Возможно я ошибаюсь, но мне кажется, что большинство сайтов времен php3 уже умерли. Почему программисты пользуются этим сейчас — для меня загадка.
Ну потому что так написано в книжке «создаем сайт с нуля за 10 дней».
UFO just landed and posted this here
Кстати автор у этой книги очень даже квалифицированный человек, взять вот например вот эту его книгу
384 страницы за 24 часа? омг.
Сайты вымерли, программисты живут и размножаются )
В таком случае какую СУБД вы бы выбрали? И главное (если можно) — почему не mysql? Сейчас у меня стоит вопрос выбора СУБД, которая будет являться основным релятивным хранилищем (далее в связке с nosql списками для поиска и memcached для статики и полустатики).
Заранее спасибо!
Заранее спасибо!
См. этот комментарий
Прошу прощения, прочитав в понедельник утром понял всё наоборот. Эх, жаль — а я думал мне достанется готовое мнение)
Если нужна реляционная БД для средних размеров проекта, выбирайте postgres или mysql.
На стадии прототипа проект будет писаться быстро, и будет совсем небольшой.
А по итогу размер проекта будет крайне, крайне большой — и больше всего будет поисков групп объектов, помеченных идентификатором (ну типа идентификаторы всех сообщений написанных проснажами с такими то идентификаторами сортированные по дате). SELECT POST_ID FROM POSTS WHERE AUTHOR_ID IN (................). Это будет максимальная нагрузка на базу — остальное будет кэшироваться и маркироваться.
А по итогу размер проекта будет крайне, крайне большой — и больше всего будет поисков групп объектов, помеченных идентификатором (ну типа идентификаторы всех сообщений написанных проснажами с такими то идентификаторами сортированные по дате). SELECT POST_ID FROM POSTS WHERE AUTHOR_ID IN (................). Это будет максимальная нагрузка на базу — остальное будет кэшироваться и маркироваться.
Ох зря вы так думаете.
В MySQLi не хватает поддержки хостерами модуля mysqlnd.dll для выполнения функции get_result() в работе с подготовленными выражениями.
> Использование prepared statements укрепляет защиту от SQL-инъекций.
Я хочу прояснить вот такой вопрос: если всегда для всех параметров использовать подготовленные выражения, то можно ли сказать, что я защищён от инъекций полностью? Не берём в расчёт драйвера, которые только имитируют работу с подготовленными выражениями. Чего стоит опасаться в таком случае?
Я хочу прояснить вот такой вопрос: если всегда для всех параметров использовать подготовленные выражения, то можно ли сказать, что я защищён от инъекций полностью? Не берём в расчёт драйвера, которые только имитируют работу с подготовленными выражениями. Чего стоит опасаться в таком случае?
Защищает от инъекций первого порядка, но не защищает от инъекций второго порядка.
Т.е. если вам в данные подсунут SQL, то он успешно заэскейпится и попадет в базу без вреда.
Но когда вы эти данные извлечете из базы и захотите использовать в запросе, вас может ждать «сюрприз».
Т.е. если вам в данные подсунут SQL, то он успешно заэскейпится и попадет в базу без вреда.
Но когда вы эти данные извлечете из базы и захотите использовать в запросе, вас может ждать «сюрприз».
UFO just landed and posted this here
>>А я так и не увидел в этой статье, почему я должен им пользоваться, а не оставаться на своем Zend_Db.
Вообще да, название статьи слишком громкое для ее содержания. Более адекватным было бы: «Основы PDO. Почему на него стоит обратить внимание.»
Вообще да, название статьи слишком громкое для ее содержания. Более адекватным было бы: «Основы PDO. Почему на него стоит обратить внимание.»
— Встроенные типы написаны на C, а не на PHP, а, следовательно, работают быстрее.
— Встроенные типы стандартизированы, а следовательно вы будете меньше зависеть от используемой ORM.
— В маленьких проектах не требующих сложных систем сокращается время запуска.
— Встроенные типы стандартизированы, а следовательно вы будете меньше зависеть от используемой ORM.
— В маленьких проектах не требующих сложных систем сокращается время запуска.
UFO just landed and posted this here
Микроскопическая разница в случае с бложиком, не такая уж и микроскопическая в случае нескольких тысяч запросов в секунду.
Не все программисты в мире используют ZF, есть еще Doctrine, Propel и сотни менее популярных проектов. Вы хотите вникать в каждый из них при переключении с проекта на проект?
Не все программисты в мире используют ZF, есть еще Doctrine, Propel и сотни менее популярных проектов. Вы хотите вникать в каждый из них при переключении с проекта на проект?
А что, разве не приходится вникать? Ни один из перечисленных вами проектов не поощряет прямые вызовы PDO.
Согласитесь, не на всех проектах требуется махина вроде Doctrine. И не все элементы системы обязаны содержать избыточный код сгенерированый вместе с нужным функционалом. У меня найдется с десяток сайтов, где я могу сделать простую деградацию до уровня PDO и выиграть за счет простоты.
Согласен, но зачем тогда Doctrine-то упоминать? Я просто в свете сказанного вами не пойму смысла фразы
Если проект использует ORM или просто библиотеку доступа к данным, при внесении в проект изменений лучше использовать именно ее. А не то там через какое-то время… мягко говоря, будет сложновато разобраться. Представляю, часть использует Doctrine, пришел другой разработчик и для простоты использует PDO. Потом следующий пришел и решил все еще проще сделать. На mysqli…
Выиграть за счет простоты можно, если в конечном итоге это не увеличит сложность… Вот такой каламбур :)
Не все программисты в мире используют ZF, есть еще Doctrine, Propel и сотни менее популярных проектов. Вы хотите вникать в каждый из них при переключении с проекта на проект?
Если проект использует ORM или просто библиотеку доступа к данным, при внесении в проект изменений лучше использовать именно ее. А не то там через какое-то время… мягко говоря, будет сложновато разобраться. Представляю, часть использует Doctrine, пришел другой разработчик и для простоты использует PDO. Потом следующий пришел и решил все еще проще сделать. На mysqli…
Выиграть за счет простоты можно, если в конечном итоге это не увеличит сложность… Вот такой каламбур :)
Смысл фразы в том, что ORM, не имея стандартных интерфейсов, тащат очень много мусора в виде драйверов и собственных реализаций этих интерфейсов, в результате чего программист теряет контроль над кодом. Именно поэтому я объединил разные по сути продукты в одно.
в результате чего программист теряет контроль над кодом.
Не могли бы пояснить, как именно?
Если рассматривать ORM, то это софт который на входе получает соединение, а на выходе дает объекты, и по сути ORM по барабану откуда она эти данные получила: MySQL, XML, BSON, JSON, стандартный массив, консольный ввод (stdin), главное чтобы эти данные были доступны по условному интерфейсу Data.
Живой пример: у нас в фирме есть корпоративная cms, которая дополняется функционалом с использованием документарной базы данных, часть модулей не соответствующих табличной форме должны переехать в эту базу. Используемая ORM не поддерживает работу с документарными бд. Какой выход из ситуации: а) сменить ORM (аха-ха) б) завести 2 ORM на время перехода, в) переписать необходимый код без использования ORM, с тем чтобы потом перевести его на новую систему. г) Дополнить код самой ORM.
Все три метода имеют явные недостатки. Ввиду того, что ORM берет на себя слишком много обязанностей. Ну и кто кого теперь контролирует? Я код или код меня?
Живой пример: у нас в фирме есть корпоративная cms, которая дополняется функционалом с использованием документарной базы данных, часть модулей не соответствующих табличной форме должны переехать в эту базу. Используемая ORM не поддерживает работу с документарными бд. Какой выход из ситуации: а) сменить ORM (аха-ха) б) завести 2 ORM на время перехода, в) переписать необходимый код без использования ORM, с тем чтобы потом перевести его на новую систему. г) Дополнить код самой ORM.
Все три метода имеют явные недостатки. Ввиду того, что ORM берет на себя слишком много обязанностей. Ну и кто кого теперь контролирует? Я код или код меня?
Но ведь с такой точки зрения использование любой внешней библиотеки (NIH) означает «потерю контроля». Более того, даже само использование PDO означает «потерю контроля», поскольку многие функции mysqli при использовании PDO недоступны.
Не совсем так. Все зависит от тесноты связывания, возьмем, такую сложную систему, как ОС, например unix: подавляющее большинство программ работают по принципу вы подаете данные на вход (stdin), получаете на выходе (stdout, stderr), по желанию они собираются в сложные цепочки с помощью различных оберток (shell-скрипты), все работает — стандартный интерфейс не ограничивает, а задает направление. И не важно, что именно вы подали на вход, главное, что эти данные могут интерпретироваться как валидные параметры для данной программы. В ситуации с обычными ORM у вас нету управляемых точек входа-выхода, только промежуточное воздействие.
Я думаю, все зависит от точки зрения. ORM — такая же программа, как и, скажем, find в Unix. Если find не умеет искать файлы с нарисованной в них собачкой — вы потеряли контроль. Придется писать алгоритм поиска собачки самому.
Отличная иллюстрация того о чем я говорю.
Find не должен искать собачек, если вам нужно найти фотографию с собачкой, вы сначала запускаете поиск по директориям, чтобы выбрать все изображения, получаете список файлов, а затем передаете его в программу поиска собачек в изображении (каждый делает то, что умеет).
Понятное дело, что недостающий функционал придется дописывать, в том случае, если он не стандартен, но существующий функционал вы можете комбинировать как угодно. ORM же замкнуты сами на себя.
Уточню, что в данной ситуации я говорю не про класс программ, а про их современные реализации.
Find не должен искать собачек, если вам нужно найти фотографию с собачкой, вы сначала запускаете поиск по директориям, чтобы выбрать все изображения, получаете список файлов, а затем передаете его в программу поиска собачек в изображении (каждый делает то, что умеет).
Понятное дело, что недостающий функционал придется дописывать, в том случае, если он не стандартен, но существующий функционал вы можете комбинировать как угодно. ORM же замкнуты сами на себя.
Уточню, что в данной ситуации я говорю не про класс программ, а про их современные реализации.
Разве про современные ORM нельзя сказать то же самое:
?
Я плохо знаю Propel, но Doctrine, по меньшей мере, данному утверждению удовлетворяет, насколько я знаю.
Понятное дело, что недостающий функционал придется дописывать, в том случае, если он не стандартен, но существующий функционал вы можете комбинировать как угодно.
?
Я плохо знаю Propel, но Doctrine, по меньшей мере, данному утверждению удовлетворяет, насколько я знаю.
> ORM же замкнуты сами на себя.
Поясните, пожалуйста.
Поясните, пожалуйста.
Лучше приведу пример. У меня есть библиотека (очень примитивная ORM) написанная на js, которая позволяет не изменяя кода работать как на клиенте так и на сервере. За счет чего это достигается? ORM, вместо того, чтобы управлять соединениями, получает объект реализующий стандартный интерфейс DataProvider. На клиенте это REST-провайдер, на сервере MongoDB-провайдер. Как вы понимаете работают они совершенно по-разному, но за счет использования стандартного интерфейса, я отделил ORM от источника данных.
Попробуйте сделать это с Propel, например. Хотя Doctrine сильно изменился за это время. Но, сомневаюсь, что он позволяет использовать файловые бд или любые другие, так же легко.
Попробуйте сделать это с Propel, например. Хотя Doctrine сильно изменился за это время. Но, сомневаюсь, что он позволяет использовать файловые бд или любые другие, так же легко.
Zend_Db может использовать PDO в качестве адаптера, так что вы спокойно можете использовать и то и другое одновременно.
UFO just landed and posted this here
Правильно, это интерфейс более высокого уровня. Зачем вы тогда спрашиваете, что из них использовать? Это все равно что спрашивать: «Мне использовать Windows или Photoshop?»
В вашем случае, нужно смотреть на тесты производительности:
PDO vs Mysqli — здесь паритет, они примерно равны
Zend_Db on PDO vs Zend_Db on Mysqli — а вот тут нужно смотреть, вот один из примеров, когда возможности драйвера PDO на порядок эффективнее их эмуляции в драйвере Mysqli.
В вашем случае, нужно смотреть на тесты производительности:
PDO vs Mysqli — здесь паритет, они примерно равны
Zend_Db on PDO vs Zend_Db on Mysqli — а вот тут нужно смотреть, вот один из примеров, когда возможности драйвера PDO на порядок эффективнее их эмуляции в драйвере Mysqli.
На вид все просто, но как обычно по нестандартным расширениям SQL тема не раскрыта, а использование нестандартных расширений не даст сменить бд сменой строки запроса. Тут разве что можно покрыть ORM подходом.
И вот основываясь на своем опыте редко бывает случай, где можно только поменять строку запроса, часто приходится переписывать чуть ли не половину запросов.
Но тут по крайней мере не придется переписывать код, использующий библиотеку.
И вот основываясь на своем опыте редко бывает случай, где можно только поменять строку запроса, часто приходится переписывать чуть ли не половину запросов.
Но тут по крайней мере не придется переписывать код, использующий библиотеку.
Согласен, в pdo очень удобно пользоваться fetch_class.
Статья неплохая, только с опозданием года на три, как минимум.
Статья неплохая, только с опозданием года на три, как минимум.
С MS Sql Server не все так просто с подключением. Для виндовой машины есть майкрософтовский драйвер, который работает очень даже не плохо — sqlsrv. Но для сервера на *nix совсем беда. Есть бесплатный FreeTDS, но есть небольшие отличия в работе от sqlsrv и запросы выполняются по очереди.
Всем хорош pdo. Пока вам не надо через pdo_oci (Oracle) работать с CLOB`ами :(
Абстракции от СУБД, ORM, Agile-методологии и прочие рефакторинги нужны для впаривания доверчивым гражданам литературных поделок сотен авторов, которых ссаными тряпками выгнали из практической разработки ©
UFO just landed and posted this here
Программисты используют возможности технологии с нативными средствами, а не используют pdo с банальными запросами к БД в надежде, что потом проект вырастет и можно будет легко перейти с (say) MySQL на PostgreSQL / Oracle / etc.
Если я пишу «коробочный» продукт (движок), то зачем мне ограничивать его пользователей в выборе СУБД, если есть простая возможность не ограничивать (в каких-то пределах)? Это про DBAL типа PDO и более высокоуровневые. А с ORM просто удобнее работать, чем с PDO или MySQLi напрямую.
С помощью PDO вы можете не меньше чем с помощью функций того же модуля mysql и даже больше. Плюс он имеет более понятный и структурированный интерфейс. Плюс не нужно запоминать тонну функций с непредсказуемыми названиями (чем итак более PHP), а использовать один инструмент для любой СУБД, не ограничивая себя в нативных возможностях. Возможно, вы не совсем представляете, что такое PDO.
Я даже скрипты из 10 строк пишу с помощью PDO.
Я даже скрипты из 10 строк пишу с помощью PDO.
Ну еще они нужны более-менее опытным программистам, которым надоело таскать из проекта в проект велосипеды.
А как он разруливает ситуации когда синтаксис запроса для выборки не подерживается определённой БД?
Например в MS SQL нету LIMIT из MySql.
Вот бы создали что-то типа LINQ как в .NET тогда было-бы весьма интересно :)
Например в MS SQL нету LIMIT из MySql.
Вот бы создали что-то типа LINQ как в .NET тогда было-бы весьма интересно :)
«Более мощный PDO», ага. Никогда универсальнее не будет мощнее того, что сделано под конкретную БД, у всех есть особенности, универсальный движок не позволит их использовать, по определению.
Кроме того, mysqli производительнее и менее требователен к памяти (особенно, если вспомнить, что он сейчас работает через mysqlnd).
Кроме того, mysqli производительнее и менее требователен к памяти (особенно, если вспомнить, что он сейчас работает через mysqlnd).
А мне нравится идея, где PDO позволяет привыкнуть к идентичным конструкциям для программирования под mysql, oracle, mssql — иначе получается что mysql и oci8 имеют приличное различие не только по синтаксису описания запросов, но даже по структурам получаемых ответов.
Мне тоже эта идея нравится и она даже работает в маленьких проектах. В больших же, когда нужна вся мощь конкретной БД, все её особенности и возможности, PDO — лишний. В Оракле есть CLOB, в MySQL у буферизированных запросов можно узнать количество строк, у кого-то есть асинхронные запросы, у кого-то — нет, ну и так далее.
Спасибо! Очень интересных ход мысли, буду разбираться дальше. Пока нашел интересную заметку по сравнению mysql_ с PDO, где PDO просто выигрывает по скорости, но видимо я потом сделаю такое профилирования для себя. ( ak33m.com/?p=59 )
теперь все работают через mysqlnd ^)
Это не сравнение mysql_ с PDO, это сравнение работы Zend_Db на PDO и Zend_Db на mysqli.
А уже прикрутили в PDO возможность просматривать исполненный прошлый запрос или так же всё и осталось с давних пор?
Добавлю. Стоит заметить, что mysql_real_escape_string и pdo->quote() работают по-разному — последние автоматически приписывают кавычки. Будьте внимательнее при переводе проектов.
PDO ограничивает в функционале, и сильно, как только вам нужно сделать что-то выходящее за рамки простых запросов.
К примеру у меня есть долгоиграющий фоновый скрипт на сервере. Отсутствие ping функционала в PDO доставляет неистовый butthurt, как и некоторый другой функционал. А поскольку в реальности совместимость между базами нужна разве что для публичных OpenSource проектов, то использование mysqli очень даже оправдано — она гораздо более функциональна чем PDO.
К примеру у меня есть долгоиграющий фоновый скрипт на сервере. Отсутствие ping функционала в PDO доставляет неистовый butthurt, как и некоторый другой функционал. А поскольку в реальности совместимость между базами нужна разве что для публичных OpenSource проектов, то использование mysqli очень даже оправдано — она гораздо более функциональна чем PDO.
Он исключения кидает, это многие не любят, лично я не приемлю такой подход к программированию в этом языке, как и сам механизм исключений по многим причинам. Кроме того, кто-то вообще не использует ООП.
Я думаю что старые интерфейсы ещё долго будут в использовании по этим причинам. Учитывая то, что тенденция кодить на исключениях (в языках, которые изначально не проектировались для этого) набирает обороты.
Я думаю что старые интерфейсы ещё долго будут в использовании по этим причинам. Учитывая то, что тенденция кодить на исключениях (в языках, которые изначально не проектировались для этого) набирает обороты.
А ещё есть DbSimple — простая и удобная библиотека для обращения к БД из PHP.
Из исходников DbSimple:
То есть используется старое расширение mysql, которое почти все рекомендуют больше не использовать.
$ok = $this->link = @mysql_connectТо есть используется старое расширение mysql, которое почти все рекомендуют больше не использовать.
Ну так и библиотека не вчера появилась — ∇ 30, в которой автор когда-то писал про DbSimple, появилась в 2003 году — почти девять лет назад.
Я не думаю, что библиотека для PHP4 (даже, если работающая в PHP5...) сейчас будет использоваться для нового проекта… тем более, что используется устаревшее расширение mysql_ (и как следствие используются не подготовленные выражения, а только их эмуляция). И кто-то спустил собак на этот код.
Однозначно PDO лучше, так как это расширение унифицирует работу с различными БД, использует подготовленные запросы и как в следствии этого бинарный протокол передачи данных(result set row binary) и различные типы курсоров.
А почему вы используете prepared statements только для UPDATE и INSERT запросов? Добавили бы в виде примера SELECT с использованием WHERE и prepared statements для безопасного заполнения условий выборки.
Вы обращаетесь к автору или к переводчику?
Потому, что при разных данных в запросах на селект вы получите разные данные, и время парсинга sql запроса будет копеечное по сравнению с временем выгребания результата.
Зато на insert запросах в задачах типа логирования или складывания в базу на лету каких-то быстро работающих парсеров — выигрышь в десятки раз. При prepared передается запрос «в формате бинари протокола, по сути в нем при бинде выделено определенное количество байт под параметры нужных типов и длины» (в кавычках не совсем точное описание на трех пальцах левой руки). Когда вы вставляете в базу миллионы записей в час — экономия на парсинге существенная
Зато на insert запросах в задачах типа логирования или складывания в базу на лету каких-то быстро работающих парсеров — выигрышь в десятки раз. При prepared передается запрос «в формате бинари протокола, по сути в нем при бинде выделено определенное количество байт под параметры нужных типов и длины» (в кавычках не совсем точное описание на трех пальцах левой руки). Когда вы вставляете в базу миллионы записей в час — экономия на парсинге существенная
Я это прекрасно знаю, но в SELECT-запросах prepared statements для условий выборки позволять избежать SQL-инъекций, если в условия подставляются сырые данные от пользователя. Я бы рассматривал именно эту сторону вопроса. Кроме того, существует достаточно узкий круг задач, например обработка больших объемов порциями, где prepared statements дадут и выигрыш в производительности.
Все еще доверяете сырым данным от пользователя? Тогда мы идем к Вам!
Мы у себя в проектах предпочитаем 10 раз перепроверить пользовательские данные, привести к нужным типам, проверить наличие неожидаемых символов и т.п. прежде, чем пихать в запросы в базу. Это не только позволяет избежать инжектов, но и массы «глюков», которые могут возникать совершенно непредсказуемо — только потому, что юзеру почему-то понадобилось ввести свой логин на эльфийском, хотя надо только английский
Мы у себя в проектах предпочитаем 10 раз перепроверить пользовательские данные, привести к нужным типам, проверить наличие неожидаемых символов и т.п. прежде, чем пихать в запросы в базу. Это не только позволяет избежать инжектов, но и массы «глюков», которые могут возникать совершенно непредсказуемо — только потому, что юзеру почему-то понадобилось ввести свой логин на эльфийском, хотя надо только английский
Я что-то говорил о доверии к сырым данным и что я им доверяю? Мою точку зрения по этому поводу можете почитать в этом комментарии, например. Но в статье речь о PDO, и соответственно я хотел бы видеть в ней использование prepared statements как еще одного рубежа защиты от SQL-инъекций. Не всегда можно с уверенностью сказать, что разработчик, который использует твой код, будет проверять входящие данные.
А я предпочитаю писать сырые данные в базу, только заэкранировав их для SQL. Хочет пользователь логин на эльфийском — ради бога. Выведу на эльфийском заэкранировав вывод только для данного формата — в html применю один экран, в json другой, в yaml третий, в php serialize четвёртый, а не буду вводимую строку приводить к наибольшему общему для SQL, html, json, yaml и php. А еси завтра понадобится ещё какой-нибудь формат — перелопачивать всю БД? А если в результате получится, что в уникальном поле в том же логине из-за вырезания небезопасного для нового формата символа получится дублирование?
Важность быстрой смены СУБД весьма преувеличена. Реальные сайты не прыгают с одной СУБД на другую ежемесячно. Да и не поможет PDO сделать это быстро и легко, если в запросах используются, специфичные для конкретной СУБД конструкции и встроенные функции. Тем не менее поддержка нескольких типов СУБД довольно востребована в коробочных CMS.
Мне в PDO нравится удобный ООП интерфейс, который, вполне самодостаточный и на значительной части проектов может быть использован без каких либо дополнительных абстрактных оболочек. Если есть необходимость расширить функционал, то можно создать класс производный от PDO.
Мне в PDO нравится удобный ООП интерфейс, который, вполне самодостаточный и на значительной части проектов может быть использован без каких либо дополнительных абстрактных оболочек. Если есть необходимость расширить функционал, то можно создать класс производный от PDO.
Перепечатка теперь разрешена на хабре? o_O ruseller.com/lessons.php?rub=28&id=610
А как со скоростью и памятью обстоят дела у PDO? Я понимаю, что при выборке в 100-200 элементов из БД разницы особой не будет.
Но, допустим, такая ситуация, что у нас одновременно к БД обращаются 1000 юзеров, которые получают по 10 000 строк из БД. Сколько памяти отъест PDO в таком случае?
PS/ Прошу прощения если вопрос кому-то покажется глупым, но я ни разу не проводил подобные исследования, бегло прочитал статью и решил задать вопрос знатокам, спасибо.
Но, допустим, такая ситуация, что у нас одновременно к БД обращаются 1000 юзеров, которые получают по 10 000 строк из БД. Сколько памяти отъест PDO в таком случае?
PS/ Прошу прощения если вопрос кому-то покажется глупым, но я ни разу не проводил подобные исследования, бегло прочитал статью и решил задать вопрос знатокам, спасибо.
Если сравнивать, то с чем?
С нативными mysql_query и mysql_fetch_assoc (например). Для меня интересно качественное сравнение — серьезно ли будет съедаться память? Ведь данные в объекте могут храниться разнообразными способами, не получится ли такой ситуации, что 256 мб оперативной памяти, которой будет с лихвой хватать для хранения выборки в массиве (после mysql_fetch_assoc) не будет достаточно для формирования BDO-объектов? Это чисто научный интерес.
Основной плюс Prepared statement — то что их можно однажды задать, а в дальнейшем много раз использовать, экономя ресурсы Mysql на парсинге. Причём экономя каждую секунду на каждом запросе для каждого посетителя.
Где пример этого? Почему в примерах я вижу везде идущие подрят $STH = $DBH-> и exec(), без какого-либо кэширования prepared statements, и в итоге скорость как у обычного mysql_query? Где информация о том, как сохранить эти prepated statements один раз и навсегда для всех посетителей между обновлениями страницы?
Где пример этого? Почему в примерах я вижу везде идущие подрят $STH = $DBH-> и exec(), без какого-либо кэширования prepared statements, и в итоге скорость как у обычного mysql_query? Где информация о том, как сохранить эти prepated statements один раз и навсегда для всех посетителей между обновлениями страницы?
А что сами пример не привели?
Хороший вопрос. Буржуйский сайт нам подсказывает ответ. Если коротко, то нельзя сохранять выражения и использовать их между соединениями.
Да, всё плохо. Тогда нет смысла использовать Prepared Statement, только если на одной странице не используется десятки одинаковых select from, что неправильно.
Либо получается надо использовать php-daemon, где все ресурсы не очищаются в конце генерации страницы (что даст не только ускорение в Prepated Statement, но и все длительные процессы инициализации тоже будут выполняться только один раз), но это нужно переделывать абсолютно всё приложение.
Либо получается надо использовать php-daemon, где все ресурсы не очищаются в конце генерации страницы (что даст не только ускорение в Prepated Statement, но и все длительные процессы инициализации тоже будут выполняться только один раз), но это нужно переделывать абсолютно всё приложение.
Если приложение выглядит как
$app = new App();
$request = new Request();
$response = $app->handleRequest($request);
$response->send();Ну если процесс интерпретатора не завершается после обработки запроса, наподобие fastcgi, то можно кэшировать данные в его адресном пространстве в промежутках, или использовать что-то типа buletcache/memcache итд.
Есть подозрение, что многие объекты PDO являются несериализуемыми и потому записи куда-то между запросами не подлежат. Если, конечно, вы не предлгаете самое расширение PDO менять.
Ну можно всегда серриализовать не сам объект, а нужные данные в кэш. В любом случае доступ к памяти процесса (пускай и чужого), быстрее чем запрос к реляционной БД.
Мы вроде о подготовленных выражениях, а не данных. То есть один процесс подготовил
SELECT * FROM users WHERE id = :id, а другие запрашивают его со своим значением id, а СУБД не тратит при каждом запросе время на парсинг запроса. Есть подозрения, что без изменения pdo/mysqlnd такую схему для mysql не реализовать.Почему не реализовать, очень даже реализовать.
То есть экземпляры PDOStatement спокойно сериализуются в одном процессе и десериализуются в другом? Это предположение или проверяли?
Я просто не вижу разницы откуда через интерфейс попадут данные в подготовленное выражение. Из стороннего процесса, или из своего процесса. У вас есть f(a, b) какая ей разница откуда попадут параметры? Главное, чтобы результат вернулся куда надо.
Если же вы тонко намекаете на то, что неплохо бы копировать само подготовленное выражение из процесса в процесс… Зачем? Если есть аккумулятор этой фигни. Но даже в этом случае, я более чем уверен, что можно и это скопировать. Ничего процессозависимого в скомпилированном выражении нет.
Если же вы тонко намекаете на то, что неплохо бы копировать само подготовленное выражение из процесса в процесс… Зачем? Если есть аккумулятор этой фигни. Но даже в этом случае, я более чем уверен, что можно и это скопировать. Ничего процессозависимого в скомпилированном выражении нет.
Я допускаю, что экземпляры PDOStatement внутри связаны с экземплярами PDO, которые в свою очередь связаны с соединениями с БД, которые принадлежат процессам. То есть это не простые PHP объекты, которые можно сохранить в кеш или сессию.
Быстрое гугление даёт docs.oracle.com/cd/E17952_01/refman-5.1-en/apis-php-mysqlnd.plugin.html по которому кажется видно, что средствами PHP задачу кэширования подготовленных выражений между запросами не решить, нужны Си-расширения, которые будут перехватывать вызовы самого PHP к драйверу mysqlnd.
Быстрое гугление даёт docs.oracle.com/cd/E17952_01/refman-5.1-en/apis-php-mysqlnd.plugin.html по которому кажется видно, что средствами PHP задачу кэширования подготовленных выражений между запросами не решить, нужны Си-расширения, которые будут перехватывать вызовы самого PHP к драйверу mysqlnd.
Правильно, либо написать расширение php на Си, либо расширение MySQL. Если сторонний демон не устраивает (я бы написал тупо сторонний демон, который держал у себя подготовленные выражения и подставлял туда данные по требованию), тогда надо разобраться как компилируются эти выражения, где они хранятся (в процессе клиенте БД, либо в демоне и взаимодействуют через сокет).
Возможно и хучить ничего не придётся.
Да, кстати, сон не отменял никто :)
Возможно и хучить ничего не придётся.
Да, кстати, сон не отменял никто :)
Та схема, которую вы привели выше, может быть реализована несколькими способами.
Результат будет один и тот же. Если вам интересно, то мы можем с вами написать пример и статью.
Результат будет один и тот же. Если вам интересно, то мы можем с вами написать пример и статью.
Дело совсем не в этом. Вы же можете создать подготовленное выражение и использовать его несколько раз подставляя в него разные значения. При этом каждый раз посылая новые значения вы не отправляете сам запрос и, соответственно, mysql не парсит этот запрос заново. Но это только в пределах одного соединения. А наступает новое соединение и этот запрос отправляется заново и парсится заново…
Предлагаю дополнить статью информацией о MYSQL_ATTR_MAX_BUFFER_SIZE. Как известно, по умолчанию этот параметр равен 1M а это значит, что из поля вы можете получить максимум 1М текста. При этом никаких ошибок не возникает.
И заодно вспомнить про соответствующий баг PHP bugs.php.net/bug.php?id=38015 связанный с проблемой установки этого параметра.
И заодно вспомнить про соответствующий баг PHP bugs.php.net/bug.php?id=38015 связанный с проблемой установки этого параметра.
Хорошо, однако, что в яве работу с базой изначально сделали в виде единообразного JDBC API — никакого разброда и шатания в стиле PHP нет.
В прошлом году присутствовал на IPC Berlin на выступлении Oracle разработчика MySQL Йоханнеса Шлютера как раз посвящённому сравнению PHP MySQL Connectors. Так вот он утверждал, что использовать нужно mysqli и ничего другого, т.к. mysql устарел, а PDO содержит баги (даже broken by design), не поддерживает все функции mysqlnd (напр. asynchronous queries, polling) и не разрабатывается постоянно дальше в отличии от mysqli, над которым активно работает непосредственно Oracle.
Скажу честно, всегда использовал PDO и был в нём уверен, но после этой лекции задумался. Слайды «PHP and MySQL — The current state» можно найти тут schlueters.de/blog/archives/145-Slides-from-IPC-and-PHP-Barcelona.html
Скажу честно, всегда использовал PDO и был в нём уверен, но после этой лекции задумался. Слайды «PHP and MySQL — The current state» можно найти тут schlueters.de/blog/archives/145-Slides-from-IPC-and-PHP-Barcelona.html
Честно говоря ожидал увидеть какие-то сравнения и бенчмарки, а не просто описание мана. Не убедило.
По опыту скажу что на отдельным местах, особенно при большой выборке, mysqli выигрывает и по скорости и по потреблению памяти, так что «не убедило».
Удобство в отдельных функциях — да, но никак не «используйте везде».
По опыту скажу что на отдельным местах, особенно при большой выборке, mysqli выигрывает и по скорости и по потреблению памяти, так что «не убедило».
Удобство в отдельных функциях — да, но никак не «используйте везде».
ИМХО, PDO нужно использовать, потому что это ООП и все его вышеописанные преимущества как раз и связаны с тем, что это ООП. В принципе, никто не мешает похожую обёртку написать для mysql_* (и функций других БД), но зачем, если уже всё сделано за нас?
По поводу Prepared statements из опыта на заметку:
Составление плана запроса может (а для постгреса оказалось именно так) выполняться на уровне подготовки запроса (prepare), соответственно без учета параметров, которые вы забиндите после. За счет этого ваша РСУБД может выбрать не лучший путь выполнения запроса (не использовать нужные индексы, использовать их в неправильном порядке и т.п.) — стоит это учитывать.
Составление плана запроса может (а для постгреса оказалось именно так) выполняться на уровне подготовки запроса (prepare), соответственно без учета параметров, которые вы забиндите после. За счет этого ваша РСУБД может выбрать не лучший путь выполнения запроса (не использовать нужные индексы, использовать их в неправильном порядке и т.п.) — стоит это учитывать.
У каждого своё мнение, у каждого свой подход и свои знания.
Моя работа не связана с ИТ, но в свободное время люблю изучить что-то новое, да и вообще работа БД и ООП.
Я не силён ни с БД ни с ООП, и для меня это замечательная статья. Возможно для профи это семечки, но я наконец понял, что к чему.
Спасибо
Моя работа не связана с ИТ, но в свободное время люблю изучить что-то новое, да и вообще работа БД и ООП.
Я не силён ни с БД ни с ООП, и для меня это замечательная статья. Возможно для профи это семечки, но я наконец понял, что к чему.
Спасибо
Дабы сэкномить вам немного нервов с ошибкой «MySQL server has gone away», ребята из Digg написали обертку:
code.google.com/p/digg/wiki/PDB
Если вы используете pdo в каком-нибудь долго работающем крон-скрипте, есть вероятность, что пока скрипт обрабатывает данные, MySQL сервер посчитает соединение заброшенным и отключит клиента. PDO сам по себе не занимается восстановлением и переподключением.
code.google.com/p/digg/wiki/PDB
Если вы используете pdo в каком-нибудь долго работающем крон-скрипте, есть вероятность, что пока скрипт обрабатывает данные, MySQL сервер посчитает соединение заброшенным и отключит клиента. PDO сам по себе не занимается восстановлением и переподключением.
В PDO при проектировании почему-то потеряли метод quoteIdentifier() (видимо авторы PDO привыкли запросы писать исключительно руками).
Плейсхолдеры реализованы из рук вон плохо. Не напишешь вроде:
$dbal->write('INSERT INTO ?table (?#) VALUES (?a)', $table, array( array_key($data), array_values($data) ))
Не говоря о более сложных вещах. Так что все равно надо над ним свою обертку писать. Но в качестве основы годится.
Плейсхолдеры реализованы из рук вон плохо. Не напишешь вроде:
$dbal->write('INSERT INTO ?table (?#) VALUES (?a)', $table, array( array_key($data), array_values($data) ))
Не говоря о более сложных вещах. Так что все равно надо над ним свою обертку писать. Но в качестве основы годится.
Очень очень напоминает Perl DBI которому уже «сотня» лет
PDO губительно для хайлоада
Только в самых минимальных ее проявлениях.
Затачивать класс под разные бд полная охинея, это удел цмсок и школяров с кучей свободного времени.
Грамотно продуманный проект по базам не бегает и не может, т.к. бд выбирается на этапе проектирования.
Только в самых минимальных ее проявлениях.
Затачивать класс под разные бд полная охинея, это удел цмсок и школяров с кучей свободного времени.
Грамотно продуманный проект по базам не бегает и не может, т.к. бд выбирается на этапе проектирования.
> PDO губительно для хайлоада
> Только в самых минимальных ее проявлениях.
Аргументы?
> Только в самых минимальных ее проявлениях.
Аргументы?
Скорость еп*та, еще какие то аргументы бывают?
Я не против пдо но не в таком дебильном виде как, например, в зенде. Хотя красиво. Но какой ценой.
Минимализм в именно данном случае оправдан.
Я не против пдо но не в таком дебильном виде как, например, в зенде. Хотя красиво. Но какой ценой.
Минимализм в именно данном случае оправдан.
Если использовать аргумент «Скорость еп*та», то можно под эту гребёнку многое чего подвести: $i++ губительно для хайлоада, echo $i.$k губительно для хайлоада, echo «текст» губительно для хайлоада и т.п.
Аргумент может быть, например, такими: «проект выдерживал только 1000 запросов в минуту, после перевода с PDO на MySql стал держать 10000», или, например, таким: «при использовании PDO, где на странице выполняется 20 запросов к базе снижает скорость выполнения в 1.5 раза по сравнению с MySQL» и т.д.
Аргумент может быть, например, такими: «проект выдерживал только 1000 запросов в минуту, после перевода с PDO на MySql стал держать 10000», или, например, таким: «при использовании PDO, где на странице выполняется 20 запросов к базе снижает скорость выполнения в 1.5 раза по сравнению с MySQL» и т.д.
>бд выбирается на этапе проектирования.
Если с момента проектирования требования изменились?
Если с момента проектирования требования изменились?
А если решили язык сменить? А если..? Ну не аргумент ведь.
И да, я согласен, что бд выбирается на стадии проектирования архитектуры приложения. Вот ни разу не видел, чтобы просто взяли и поменяли базу в работающем проекте. Попутно — видел (вместе с половиной приложения поменяли), но просто базу — никогда.
И да, я согласен, что бд выбирается на стадии проектирования архитектуры приложения. Вот ни разу не видел, чтобы просто взяли и поменяли базу в работающем проекте. Попутно — видел (вместе с половиной приложения поменяли), но просто базу — никогда.
Вы так все увлеклись холиварами, что слона то вы и не заметили кучу синтаксических ошибок в исходном (не переведенном) и текущем вариантах вы и не заметили.
Специально не буду писать в ЛК, ибо писал уже, надеясь что автор после этого перечитает свою статью и статью автора, которую весь интернет с ошибками процитировал.
Скрины пойдут с сайта оригинала, дабы не уличать в ошибках автора перевода, но я надеюсь он быстро поправит, ну и жаль что автор так торопился об этом написать, что правило «доверяй но проверяй» как-то позабылось. Буду разжёвывать, ибо в топик могут заглянуть начинающие программеры, воспользоваться кодом, и после того как нихрена не заработает вернуться к старомудедовскому способу mysql_query.
поехали:
кавычки не том на месте, об этой ошибке я автору перевода, далее ТС (ТопикСтартеру) отписал
подсветка синтаксиса как бы намекает, что строка продолжается, кавычка не закрыта.
Ну и понеслось, где метод между $DBH-> и ( или мы должны сами перелопатить документацию и догадаться что там $DBH->prepare() ???
то же самое, нет метода $DBH->prepare() и ошибка в синтаксисе INSERT INTO… VALUES
об этой ошибке я тоже ТС сообщил, но он не правильно исправил на:
От себя бы еще добавил два очень важных момента, ибо знать их надо:
1.
exec конечно хорошо, но почему ничего не сказано про driver options?
например для pdo_mysql:
все три переменных установятся в одном запросе при соединении с БД
2.
execute экранирует все переменные, поэтому такой код с mysql выражением у вас не сработает:
придётся обойтись без переменной:
Извините если комментарий получился огромный, но информация об ошибках должна быть такой — видной и заметной! Кстати в оригинале до сих пор ошибки не поправлены, о них я тоже уведомлял. Печально всё это, для кого пишутся статьи на скорую руку?
Ставлю автору большой минус за то, что не проверил размещенный им материал, даже после получения информации о двух опечатках. Я если честно поначалу подумал, что это ошибки ТС, ан нет.
Специально не буду писать в ЛК, ибо писал уже, надеясь что автор после этого перечитает свою статью и статью автора, которую весь интернет с ошибками процитировал.
Скрины пойдут с сайта оригинала, дабы не уличать в ошибках автора перевода, но я надеюсь он быстро поправит, ну и жаль что автор так торопился об этом написать, что правило «доверяй но проверяй» как-то позабылось. Буду разжёвывать, ибо в топик могут заглянуть начинающие программеры, воспользоваться кодом, и после того как нихрена не заработает вернуться к старому
поехали:
кавычки не том на месте, об этой ошибке я автору перевода, далее ТС (ТопикСтартеру) отписал
подсветка синтаксиса как бы намекает, что строка продолжается, кавычка не закрыта.
Ну и понеслось, где метод между $DBH-> и ( или мы должны сами перелопатить документацию и догадаться что там $DBH->prepare() ???
то же самое, нет метода $DBH->prepare() и ошибка в синтаксисе INSERT INTO… VALUES
об этой ошибке я тоже ТС сообщил, но он не правильно исправил на:
От себя бы еще добавил два очень важных момента, ибо знать их надо:
1.
exec конечно хорошо, но почему ничего не сказано про driver options?
например для pdo_mysql:
$driver_options = array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET names = 'utf-8', lc_time_names = 'ru_RU',time_zone = 'Europe/Moscow'");
$DBH = new PDO("mysql:host=$host;dbname=$dbname", $user, $pass, $driver_options);
все три переменных установятся в одном запросе при соединении с БД
2.
execute экранирует все переменные, поэтому такой код с mysql выражением у вас не сработает:
$data = array( 'id_user' => $id_user, 'visit_date' => 'NOW()' );
$STH = $DBH->("INSERT INTO `auth_logs` (id_user, visit_date) VALUES (:id_user, :visit_date)");
$STH->execute($data);
придётся обойтись без переменной:
$data = array( 'id_user' => $id_user );
$STH = $DBH->("INSERT INTO `auth_logs` (id_user, visit_date) VALUES (:id_user, NOW())");
$STH->execute($data);
Извините если комментарий получился огромный, но информация об ошибках должна быть такой — видной и заметной! Кстати в оригинале до сих пор ошибки не поправлены, о них я тоже уведомлял. Печально всё это, для кого пишутся статьи на скорую руку?
Ставлю автору большой минус за то, что не проверил размещенный им материал, даже после получения информации о двух опечатках. Я если честно поначалу подумал, что это ошибки ТС, ан нет.
Респект. Обычно читаешь в топиках семантику, а синтаксису доверяешь, рассчитывая, что он проверен… И холиваришь насчёт семантики, если речь не идёт о микросекундах, а о стиле :( Не говоря о том, чтобы сравнивать оригинал и перевод (я даже не заметил, что это перевод — 100500-й минус хабру за юзабилити)
P.S. С Now() вообще всё сложно: вроде, с одной стороны, удобная конструкция, а с другой плохо кэшируется на уровне мускула и не гарантирует, что пришедший раньше на сервер запрос выберет из (или внесёт в) БД только те данные, которые были до начала запроса, потому считаю, что лчше без особых причин использовать
P.S. С Now() вообще всё сложно: вроде, с одной стороны, удобная конструкция, а с другой плохо кэшируется на уровне мускула и не гарантирует, что пришедший раньше на сервер запрос выберет из (или внесёт в) БД только те данные, которые были до начала запроса, потому считаю, что лчше без особых причин использовать
> execute экранирует все переменные
Классическая ошибка или непонимание подготовленных выражений.
Классическая ошибка или непонимание подготовленных выражений.
а например такой код через PDO как правильно реализовать?
$vote = (int) $_POST['vote'];
$id_user = (int) $_POST['id_user'];
// классический вариант без PDO
$sql = "UPDATE `photo_votes` SET `vote` = `vote`+" . $vote . " WHERE `id_user` = '" . $id_user . "' ";
$result = mysql_query($sql);
При чём тут это?
какое здесь должно быть подготовленное выражение?
Вы можете его сами прекрасно написать. Зачем Вам нужно, чтобы это сделал я? Поясните свою мысль без выходов из-за печки.
Вы пишите о не правильном понимании подготовленных выражений, мне хотелось бы увидеть вашу точку зрения на «понимание» как оно правильно на конкретном примере
> execute экранирует все переменные, поэтому такой код с mysql выражением у вас не сработает:
Не экранирует ничего execute… Если СУБД поддерживает подготовленные выражения, то ничего никто не экранирует, а данные идут в базу отдельным пакетом. Если СУБД не поддерживает подготовленные выражения, то их эмулирует соответствующий драйвер(экранирует, кодирует — не важно). Если мы говорим про mysql, то используются именно полноценные подготовленные выражения. Вот пример:
На всякий случай ссылка. Данные не экранировались, а вставились в запрос как есть.
Не экранирует ничего execute… Если СУБД поддерживает подготовленные выражения, то ничего никто не экранирует, а данные идут в базу отдельным пакетом. Если СУБД не поддерживает подготовленные выражения, то их эмулирует соответствующий драйвер(экранирует, кодирует — не важно). Если мы говорим про mysql, то используются именно полноценные подготовленные выражения. Вот пример:
# mysql
mysql> PREPARE stmt1 FROM 'SELECT ? AS `title`';
mysql> set @title = "--''''''''!@#$%^&*()_+////\"\\";
mysql> EXECUTE stmt1 USING @title;
+------------------------------+
| title |
+------------------------------+
| --''''''''!@#$%^&*()_+////"\ |
+------------------------------+
1 row in set (0.00 sec)
На всякий случай ссылка. Данные не экранировались, а вставились в запрос как есть.
Это всё понятно, вы меня не правильно поняли. Я имел ввиду экранизацию на уровне вставки из приложения, для защиты от SQL инъекций (аналог mysql_real_escape_string).
И мы тут как бы про PDO говорим, так и давайте в контексте PDO и делать запросы.
Вы здесь слукавили и заэкранировали кавычку \"
В мануале по execute в разделе input_parameters написано, что все данные будут интерпретированы как строки (PDO::PARAM_STR).
В связи с чем тут проблема в том, что иногда эту экранизацию в приложении надо отключать, например для конкретных SQL выражений смешанных с PHP переменными, но штатных способов через bindValue нету. Поэтому приходится прям в самом выражении по старинке вот так вот делать:
когда как в Zend_Framework данная финча реализуется оборачиванием SQL выражения (скобками):
Вообщем в PDO не хватает константы PDO::PARAM_EXPR (либо есть какое то решение о котором я не знаю ?) для отключения экранизации через bindValue:
надеюсь мысль понятна.
И мы тут как бы про PDO говорим, так и давайте в контексте PDO и делать запросы.
Вы здесь слукавили и заэкранировали кавычку \"
mysql> set @title = "\"";
В мануале по execute в разделе input_parameters написано, что все данные будут интерпретированы как строки (PDO::PARAM_STR).
«An array of values with as many elements as there are bound parameters in the SQL statement being executed. All values are treated as PDO::PARAM_STR.»
В связи с чем тут проблема в том, что иногда эту экранизацию в приложении надо отключать, например для конкретных SQL выражений смешанных с PHP переменными, но штатных способов через bindValue нету. Поэтому приходится прям в самом выражении по старинке вот так вот делать:
$user_id = $_GET['u'];
$user_ip = $_SERVER['REMOTE_ADDR'];
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$STH = $DBH->prepare("UPDATE `auth_login` SET `hash` = SHA1(CONCAT(`salt`), '".$user_ip."', '".$DBH->quote($user_agent)."') WHERE `id_user` = :id_user");
$STH->bindValue(':id_user', $user_id, PDO::PARAM_INT);
когда как в Zend_Framework данная финча реализуется оборачиванием SQL выражения (скобками):
$db->update( 'auth_login', array( 'hash' => '(SHA1( CONCAT(`salt`, '".$user_ip."', '".$db->quote($user_agent)."') ))' ) );
Вообщем в PDO не хватает константы PDO::PARAM_EXPR (либо есть какое то решение о котором я не знаю ?) для отключения экранизации через bindValue:
$STH->bindValue(':hash', 'SHA1( CONCAT(`salt`, '".$user_ip."', '".$DBH->quote($user_agent)."') )', PDO::PARAM_EXPR);
надеюсь мысль понятна.
Так и не понял — чем PDO лучше mysqli.
Я так думаю реализацией и поддержкой. PDO — объетно-ориентированный подход, и как следствие абстрактные методы для работы с БД, благодаря которым можно легко мигрировать с одной БД на другую, использовать одинаковые методы для работы с любой базой (если она эти методы поддерживает), в mysqli — процедурный подход и работает эта библиотека только с MYSQL. Но судя по отзывам PDO сырой, в нём есть баги и этим расширением никто не занимается, в отличие от mysqli который более стабильный и поддержкой которого занимается Oracle.
чорт не минусуйте, в mysqli возможны оба варианта: и процедурный и ООП подход. Я им честно не пользовался напрямую, я так думаю здесь разница лишь в удобности мигрирования, хотя всю туже самую миграцию можно осуществить своими классами, как это сделали в Zend_Framework.
mysqli вполне себе поддерживает ОО подход.
основных различий только два:
1) PDO поддерживает много движков БД, а mysqli — только MySQL;
2) PDO поддерживает именованные плэйсхолдеры (WHERE `id_user` = :id_user), а MySQLi — нет.
Вот и всё. Отсутствие процедурного стиля работы с PDO особенно обсуждать не имеет смысла. PDO чуть-чуть медленнее MySQLi, но оба они проигрывают по скорости простому расширению mysql.
1) PDO поддерживает много движков БД, а mysqli — только MySQL;
2) PDO поддерживает именованные плэйсхолдеры (WHERE `id_user` = :id_user), а MySQLi — нет.
Вот и всё. Отсутствие процедурного стиля работы с PDO особенно обсуждать не имеет смысла. PDO чуть-чуть медленнее MySQLi, но оба они проигрывают по скорости простому расширению mysql.
mysqli имеет и объектный интерфейс — раз.
переходить на другую СУБД приходилось только один раз в жизни — в последний месяц. SQLite->MySQL.
Страшно не было — правда :)
переходить на другую СУБД приходилось только один раз в жизни — в последний месяц. SQLite->MySQL.
Страшно не было — правда :)
Может кто скажет, статья еще актуальна?
Sign up to leave a comment.
Почему стоит пользоваться PDO для работы с базой данных