Несколько советов от профи (php, mysql)

Пятница...

Можете начать.

Я лишь указал путь развития на конкретном примере.

Yii - легче зенда )

TF-Studio, Slim2 легче обоих

П.С. не истины ради, а холивара для :)

Первый try catch. - Тут я могу сказать обратное. Писать эту конструкцию в методе, который в 99% выполняется без ошибок - смерть в перспективе для производительности.

Стоит обратить внимание на throw, который инициализирует запись ошибки в лог Apache, а это плюс одна файловая операция.

А второй? 🍿

mysqli вместо PDO ;)

Dinozavr, догадывался. Ну опять-таки, у меня приоритет на производительность кода. PDO работает медленнее. :p

ortegas, это вы так по пятницам шутите?:)

Dinozavr, PDO - жирный монстр. Жирный и неуклюжий. Использовать PDO ради одного языка, то самое, что использовать jQuery ради одной функции.

PHP рекомендует использовать mysqli.

[ATTACH]133235[/ATTACH]

явки, пароли, док-ва?

Вы не забывайте, что с PDO SQL-Injection невозможна, а с mysqli вам придётся об этом заботиться самому

Dinozavr, для меня, PDO в проекте - верный признак халтуры.

Все входящие данные у меня проверяет отдельный метод. Я указываю все допустимые $_POST, $_GET, $_COOKIE, их тип, максимальную и минимальную длину или значения (для цифровых значений), надобность в экранировании специальных символов. Данные, которые проходят валидацию попадаю в $_SESSION (memcached), где номер объекта равняется UNIX время запроса.

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

А что ваш PDO::prepare? Он расходует ресурсы на парсинг текста, и фактически только экранирует специальные символы и валидирует SQL запрос, который у меня в production версии обязательно верный. Я уже молчу о том, что данные $_SESSION у меня сохраняются и после завершения работы скрипта, я могу их использовать многоразово, когда PDO валидирует запрос и данные каждый раз.

Рассмотрим пример. Ожидается FLOAT под $_POST['id'].

Мой метод: (float) $_POST['id'].

PDO: prepare, execute(['id' => (float) $_POST['id']]) (проверка на спец. символы).

Вопрос: зачем инициализировать поиск спец. символов в FLOAT, INT, STRING, которые пользователь не может изменить? Это нужно только в случае входящего STRING, для такого случая, у меня есть тип SQL.

Моя структура гарантирует не только невозможность SQL инъекций, а и валидность каждого входящего параметра. А Database служит только посредником для непосредственно исполнения SQL запросов. В которых ошибок по существу быть не может.

Каждый метод (даже connect) в PDO выполняется медленнее - причины очевидны. Чем сложнее конструкция - тем сложнее и медленнее выполнение. Возможно, PDO кому-то и полезен, например, криворуким новичкам, но в любом серьезном проекте, рано или поздно будет поставлен вопрос об оптимизации производительности - отказе от PDO.

как бы намекает...

а вообще мне нравится ваш метод приведения доказательств

ну а теперь, о великий гуру, поведайте нам неучам сколько и какие вы highload проэкты реализовали, чтобы так уверенно хаять PDO.