Форум MySQL

Добрый день.
Прочитал кучу статей, посмотрел синтаксис, возможности MYSQL, MySQLi и PDO и так и не понял, какие конкретно преимущества у MySQLi перед MYSQL? Помимо мнимой «безопасности» и возможностей ООП, которые на большинстве проектов не нужны. Стоит ли существующие (старые) проекты, которые годами успешно работают на MYSQL переводить на MYSQLi? Что делают гиганты в данной отрасли типа google, facebook, сервисы mail.ru и.т.д. Они будут все коды переписывать? Я лично считаю, что единственное, ради чего стоило бы переписывать – это ради перехода на новые версии PHP, в которых уделяется внимание вопросам безопасности и производительности. Основной вопрос, собственно, по PHP.

- Подскажите, пожалуйста, с какого это перепуга разработчики PHP решили с версии PHP5.5 отказаться от поддержки MYSQL? Как по мне, реальные проекты на MYSQL (конкретно типовые операции выборки, удаления, обновления записей из базы данных) будут работать пошустрее, чем на MYSQLi. Или по крайне мере не медленнее. Так смысл тогда переписывать?

С уважением .

Прочитал кучу статей
судя по тому что вы тут написали, вы не прочитали, а бегло пробежались не понимая о чем реч.
Во первых запомните раз и навсегда, есть база данных MySQL (точка)
Из РНР с СУРБД можно работать с помощью драйверов mysql_ , mysqli_ и PDO (у этой библиотеки вроде как с недавних пор свой драйвер работы с MySQL, а до этого, вы не поверите был mysqli, и суть этой библиотеки отделить логику кода на РНР от какой-то конкретной БД, т.е. программе на РНР все равно какая БД будет использоваться)
драйвер mysql_ просто устарел и поэтому его уберут, на его смену пришел драйвер mysqli_ (еще в 2007 году!!!) который помимо процедурного стиля поддерживает стиль ООП.

"просто" - ничего не бывает. Не понял, чем mysqli_ лучше mysql_?
И стоит ли переписывать проекты, которые с 2005-2006-го года нормально работают буз mysqli_?
Какой смысл? Какие конкретные преимущества будут? Сегодня у них mysqli_ , завтра появится mysqlX_, а от mysqli_ - откажутся в версии PHP5.6. Что, переписывать каждый раз под них? Почему нельзя было дорабатывать mysql? Неужели вы думаете, что mysqli_ - был создан с нуля?

вы ботинки новые покупаете, и ли старые постоянно ремонтируете?
на самом деле грамотно написаный код не составляет труда перевести с mysql_ на mysqli_
хотите пререписывайте, хотите нет, вас никто не будет ждать

Если на процедурный mysqli_, то.. может быть. А если на ООП?
И вообще если уж использовать mysqli_, то как лучше? Сразу на ООП или это дело вкуса?
Плохо, когда выбор есть... )

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

Увы, или переписывать каждый раз, или держать свой сервер со старыми версиями программ

VPS стоит копейки, если что. И держите на нем что хотите.

> И стоит ли переписывать проекты, которые с 2005-2006-го года нормально работают буз mysqli_?
Если не собираетесь менять код и версию ПХП - смысла нет

>Они будут все коды переписывать?
они то не будут, а вот вам, с таким отношением к ооп, видимо придется

У них вообще мускул только урывками встречается. И уж тем более пхп. И уж тем более зависимость связки мускул+пхп

До сих пор пользуюсь mysql. Никто не знает есть ли хорошие статьи или лучше книги, где бы описывалось расширение mysqli? Я нашел небольшую статью и мануал. Этого недостаточно.

лучше pdo

чем лучше?

новее, актуальнее. сменить субд, в случае чего, можно будет достаточно просто. а еще в pdo есть именованные параметры

Можно, подумать, что "в случае чего" - происходит каждый день.
pdo - работает медленнее, чем mysql_ или mysqli_
Самая шустрая база данных - mysql. Как по мне, лучше с mysql_ переходить на mysqli_
Только пока в раздумьях, на процедурный стиль или ООП.

процедурного стиля там все меньше и меньше

можно подумать, что ~2.5% для обычных запросов и ~6.5% для подготовленных выражений в производительности вы хоть как-то почувствуете. гораздо важнее делать правильную нормализацию, расставлять правильно индексы и составлять грамотно запросы. вот что действительно может сильно сказаться на результате

> pdo - работает медленнее, чем mysql_ или mysqli_
> Самая шустрая база данных - mysql.
Вы так и не усвоили, что говорите о драйверах доступа к одной и той же СУБД.
Все трое - это MySQL (в данном конкретном случае). Вопрос только как к ней обращаться.

> Самая шустрая база данных - mysql.
А это вообще у меня вызывает таааааакие сомнения.....

Скорее всего имелось ввиду что оверхед реализации PDO выше, чем mysqli. Возможно это и так из-за большей абстрагированности и эмуляции фич, но на практике об этом стоит беспокоиться в самую последнюю очередь.

Что касается производительности СУБД, то, пока не реализуешь свой проект для разных СУБД и не посмотришь поведение на продакшене, завяления в стиле "mysql решает" и "что-то сомневаюсь" абсолютно беспочвенны и стоит игнорировать как холиварные.

> сменить субд, в случае чего, можно будет достаточно просто
Вы вот каждую неделю СУБД меняете??? Это мифический плюс.

дело не в том, насколько часто меняю я, а в том, что это еще одно очевидное преимущество pdo по сравнению с другими.

Если вы разрабатываете библиотеку и не можете заранее предугадать какая СУБД будет у пользователей, то абстрагированность PDO сложно переоценить в таком случае.

Вот статья по mysqli на английском языке, правда тут рассматривается исключительно ООП-вариант.

Расширение mysql не развивается ещё со времени выхода mysql 4.1. Соответственно, новый функционал не добавляется, баги не фиксятся. Не понимаю, почему они тянут аж до 5.5, когда его можно было выпилить уже в 5.3.
Даже когда исчезнет это расширение, старый код, использующий его, всё равно можно будет запустить. Нужно просто самостоятельно реализовать mysql_* функции и под капотом использовать PDO/mysqli.

Mysqli реализует большое количество новых фич mysql, активно поддерживается сообществом. В теории, дебажить с этим расширением проще из-за наличия нескольких дебаг функций. Развитое API.

PDO ориентирован на переносимость. Если одновременно используется несколько различных СУБД, проще воспользоваться абстракцией PDO. Так же с PDO проще переехать на новую СУБД. По этим причинам на нём обычно останавливаются создатели публичных библиотек общего назначения, типа doctrine, yii и т.п. Так же PDO проще в использовании, чем mysqli.

В общем, не имеет большого значения какое расширение использовать. Лично я выбрал PDO. С ним код получается проще и понятнее (а это облегчает дальнейшую поддержку). Но даже в этом случае, я пользуюсь обёрткой над PDO - добавляю таким образом нужные мне фишки и абстрагируюсь от mysql слоя. При таком подходе уже в принципе не важно какое расширение используется. Все детали инкапсулируются обёрткой и легко можно заменить одно расширение на другое, не трогая весь остальной код.

Компании уровня mail.ru и facebook не пользуются соединениями к БД напрямую. Почти наверняка есть ещё один абстрактный слой, который подгоняется под требования и задачи компании. Например, ни один из драйверов не способен прозрачно для остального кода перепослать запрос на запасной сервер, если основной отказал.

Не понимаю, почему они тянут аж до 5.5, когда его можно было выпилить уже в 5.3.

Предыстория. Когда-то давно, когда еще деревья были большими делалось два небольших проекта под Денвер, под версии 5.4, использовалось расширение mysql, причем размещение их в папках www. Затем, спустя время, при переходе на OpenServer, эти проекты были перенесены тоже на него, но помещены скрипты были без вложения в папки www.

Требовалась разработка под v.5.5, а в OS был подключен РНР 5.6. И тут возникла потребность вернуться к проектам старым, результат:

Один из проектов (назовем его 1, так как он более ранний был) выдавал в итоге 403.
Второй проект без проблем работал, то есть никаких ошибок, даже по поводу mysql, нет.

После переноса проекта 1 в папку www он стал реагировать на запросы, но с ошибкой о "древности mysql" сразу на стадии подключения.

Так и не понял причину 403, так и не понял почему на mysql_connect() для проекта 1 получаем логичное предупреждение, а для второго нет проблем. Если говорить о какой-то разнице между проектами в плане базы, то это только cp1251 у первого, и UTF у второго. Вот и думаешь чей тут баг и что за интересная ситуация.

Jaroslav, обёртка — функция или класс, инкапсулирующие работу с базой. Новый уровень абстракции.

Пример:

<? class Db {   protected $_dsn;   protected $_username;   protected $_passwd;   protected $_options;   protected $_pdo;   public function __construct($dsn, $username = null, $passwd = null, array $options = null) {     $this->_dsn = $dsn;     $this->_username = $username;     $this->_passwd = $passwd;     $this->_options = $options;   }   public function getConnection() {     if ( !$this->_pdo ) {       $this->_pdo = new PDO($this->_dsn, $this->_username, $this->_passwd, $this->_options);     }     return $this->_pdo;   }   public function query($sql) {     return $this->getConnection()->query($sql);   } }

В данном примере используется техника lazy initialization.

Обёртки могут быть простые (как в моём примере), так и монстры уровня doctrine. Обычно их строят для абстрагирования от используемых внутри инструментов и для дополнения недостающей функциональности. Например, в мой пример можно легко добавить контроль длительности запросов.

PS
Jaroslav, по электронной почте не консультирую. Пишите сразу сюда, на форум.

Не лучше Singleton в примере перенести в конструктор?

не лучше

Тут не используется singleton.

Ну, я имел виду нижеследующий код, хотя, согласен, в определении ошибся.

if ( !$this->_pdo ) {       $this->_pdo = new PDO($this->_dsn, $this->_username, $this->_passwd, $this->_options);     }     return $this->_pdo;

В этом коде и содержится вся суть отложенной инициализации.

Можно один раз в конфиге инициализировать эту обёртку и в дальнейшем использовать её везде. Если получится так, что все нужные для построения страницы данные будут получены из кеша и не будет совершено ни одного запроса к базе, то мы сэкономим время и ресурсы, необходимые на установление соединения к бд.

Тогда уж проще не лезть в нативный ПХП и уж тем более не вдаваться в тонкости доступа и функций, а просто взять цмс с готовой орм.

Далеко не всегда нужна тяжелая артиллерия. Тем более все они, в конце концов, написаны на нативном php.