Комментарии 7
Минусы странные какие-то. Если периодически падает с ошибкой без причины и этот вопрос не решается — это не минус, а не возможность использования в продакшене в принципе. А mysqli я бы давно уже вырезал из поддержки, PDO же объективно лучше
Хорошее замечание, пожалуй надо было об этом оговориться в посте. По порядку:
Если периодически падает с ошибкой без причины и этот вопрос не решается — это не минус, а не возможность использования в продакшене в принципе.
Справедливости ради надо сказать, что внезапное падение не обязательно решается перезагрузкой.
Часть фукнционала php просто не поддерживается хип-хопом и придётся переписывать код, т.к. иначе могут быть неожиданные ошибки — например, может не понять класс или ещё что-нибудь. Поэтому я и не говорю что его надо устанавливать на любой сервер или что это оптимальное решение. Просто это опенсорс, и он позволяет выполнять скрипт значительно быстрее. Тем не менее, как всегда в этом случае, после установки ещё будет с чем повозиться. Не упомянуть об этом минусе, я считаю, было нельзя, однако если бы это решение было несовместимо с продакшеном, его бы, вероятно, не использовали совсем. Оно просто не идеально.
Теперь по поводу А mysqli я бы давно уже вырезал из поддержки, PDO же объективно лучше
Я бы не сказал, что mysqli фигня и от него надо отказаться. Конечно, технология более старая, но, кстати, она быстрее. Как я уже говорил, во всём свои плюсы и минусы. В вашем случае «необходимость» использовать PDO — это очевидный плюс, т.к., получается, что вы наоборот предпочитаете технологию более новую. Возможно, мне надо было оговориться сразу, что для кого-то это будет плюс, а для кого-то минус.
Если периодически падает с ошибкой без причины и этот вопрос не решается — это не минус, а не возможность использования в продакшене в принципе.
Справедливости ради надо сказать, что внезапное падение не обязательно решается перезагрузкой.
Часть фукнционала php просто не поддерживается хип-хопом и придётся переписывать код, т.к. иначе могут быть неожиданные ошибки — например, может не понять класс или ещё что-нибудь. Поэтому я и не говорю что его надо устанавливать на любой сервер или что это оптимальное решение. Просто это опенсорс, и он позволяет выполнять скрипт значительно быстрее. Тем не менее, как всегда в этом случае, после установки ещё будет с чем повозиться. Не упомянуть об этом минусе, я считаю, было нельзя, однако если бы это решение было несовместимо с продакшеном, его бы, вероятно, не использовали совсем. Оно просто не идеально.
Теперь по поводу А mysqli я бы давно уже вырезал из поддержки, PDO же объективно лучше
Я бы не сказал, что mysqli фигня и от него надо отказаться. Конечно, технология более старая, но, кстати, она быстрее. Как я уже говорил, во всём свои плюсы и минусы. В вашем случае «необходимость» использовать PDO — это очевидный плюс, т.к., получается, что вы наоборот предпочитаете технологию более новую. Возможно, мне надо было оговориться сразу, что для кого-то это будет плюс, а для кого-то минус.
Вы оба не совсем понимаете, что такое mysqli. Отвечу сразу обоим.
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
Ну если уж на то пошло, то ваше сравнение магнитолы и плеера вообще не корректное. PDO это общая система доступа к бд через кучу драйверов, а mysqli как гласит название для mysql. Именно поэтому я и поставил плюс pdo. Правильнее было бы написать про сравнение магнитолы с возможностью подкручивать головку отверткой и домашней медиасистемы способную проигрывать что угодно, но без тонких настроек, без которых 95% проживет.
Во-первых, не плеера, а деки. Я понимаю, что несколько старомоден в своих аналогиях, но уж что первое в голову пришло :)
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Ага, сам нашел. Сейчас только мускуль и лайт.
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
Согласен с FanatPHP по поводу фанатичного вырезания mysql* решений по желанию левой пятки правой индусской ноги. Меня вообще убивает, зачем тот же mysql хотят вырезать из php7. Работает себе, есть не просит, куча готового кода с ним есть, кто знает как правильно экранировать данные не видит смысла в переходе и в перелопачивании тонны кода. Но индусу разработчики PHP опять доказывают что им наплевать на обратную совместимость.
У меня есть вопрос по поводу массивов в HHVM. Я не вижу ускорения работы с ними, и к тому же они почему-то потребляют в 3 раза больше памяти по сравнению с тестовыми сборками PHP7.
Spl так вообще в раз в 10 медленнее в HHVM по сравнению с обычными массивами и не показывают уменьшение памяти.
Вот ссылка на мой бенчмарк 3v4l.org/8QZcN, по мотивам которого видимо можно написать целую статью о мифах и легендах. Например:
— в последнем HHVM 3.6.0 доступ к массиву с числовым ключом, заданному через константу define, по прежнему медленее, чем доступ по числу, но быстрее чем по «string». Хвалёный компилятор не может константы define полностью приравнять к числам? В предыдущих hhvm, особенно 3.5.1 так вообще быле регрессия, define было в 2 раза медленнее «string».
— аналогично в ночных сборках php7, define быстрее “string” но медленнее integer. Не зря существуют отдельные расширения для PHP, которые ускоряют константы. Когда же это появится в PHP из коробки?
— php7 в этом тесте на массивах в 2 раза быстрее HHVM 3.6.0 на “string” и define, и в 1.5 раза на числовых индексах. У 3.6.0 наблюдается регрессия в скорости массивов почти в 2 раза по сравнению с предыдущими версиями.
— spl в 5.6.7 не быстрее define и integer, только лишь немного лучше по памяти до 25%
— во всех версиях php ниже 5.6 доступ к массиву по константе define медленнее даже “string”
У меня есть вопрос по поводу массивов в HHVM. Я не вижу ускорения работы с ними, и к тому же они почему-то потребляют в 3 раза больше памяти по сравнению с тестовыми сборками PHP7.
Spl так вообще в раз в 10 медленнее в HHVM по сравнению с обычными массивами и не показывают уменьшение памяти.
Вот ссылка на мой бенчмарк 3v4l.org/8QZcN, по мотивам которого видимо можно написать целую статью о мифах и легендах. Например:
— в последнем HHVM 3.6.0 доступ к массиву с числовым ключом, заданному через константу define, по прежнему медленее, чем доступ по числу, но быстрее чем по «string». Хвалёный компилятор не может константы define полностью приравнять к числам? В предыдущих hhvm, особенно 3.5.1 так вообще быле регрессия, define было в 2 раза медленнее «string».
— аналогично в ночных сборках php7, define быстрее “string” но медленнее integer. Не зря существуют отдельные расширения для PHP, которые ускоряют константы. Когда же это появится в PHP из коробки?
— php7 в этом тесте на массивах в 2 раза быстрее HHVM 3.6.0 на “string” и define, и в 1.5 раза на числовых индексах. У 3.6.0 наблюдается регрессия в скорости массивов почти в 2 раза по сравнению с предыдущими версиями.
— spl в 5.6.7 не быстрее define и integer, только лишь немного лучше по памяти до 25%
— во всех версиях php ниже 5.6 доступ к массиву по константе define медленнее даже “string”
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HHVM (hip-hop): Сравнительное тестирование и настройка