PDO внештатное?
кэширование не повышает производительность, снимая нагрузку?

Зачем лепить ООП там, где можно запросто обойтись без него?

ах да, теперь очевидно, мы же экономим на всем что движется. А что не движется, заставляем двигаться и еще раз экономим. И какая кому разница, что все эти оптимизации на фоне ввода/вывода равны нулю...

Что делать? По-моему, все очевидно - использовать ;) Если же фреймворк окажется мертвым кодом, то тут дело в: 1) ДНК, 2) фреймворке, 3) задаче. Последний пункт случается редко, так что остается одно из двух :)

ну да, ну да. Абстрактные взятые с потолка цифры всегда производят впечатление на неокрепшие умы.

можно и от создания своих функций отказаться, но кому от этого легче будет? Или вообще создавать сайты на C в виде расширений для php

мы обсуждаем сферическую задачу в вакууме и вы всерьез рассчитываете попасть пальцем куда-либо, кроме как в небо, с обобщениями типа "1. Не используйте ООП. 2. Если все же надо, см. пункт 1"?

Я никого не призываю не использовать ООП, а лишь спрашиваю, чем использование ОО-подхода выгодней в данной конкретной ситуации.
Возможно я предвзято отношусь к нему и изменю свою точку зрения, если вы укажите объективные доводы в пользу него.

ситуация не очень конкретна. Если речь идет о том, чем лучше pdo по сравнению с mysql: 1) с ним нельзя наткнуться на проблемы перобразования в int или, кстати, sprintf("%d...), 2) поддержка исключений, 3) однообразный интерфейс для работы с разными БД - не надо для каждой БД учить ее собственный интерфейс, 4) может еще чего, транзакции, например, там есть. Насколько они важны, в каждом конкретном случае решается отдельно. Минусы PDO - немножко более сложный интерфейс. А разницу в производительности, я уверен, вы не заметите. К тому же, у mysql по сути тоже ООП-интерфейс, просто сделан он без использования "настоящих" объектов.

Если же речь идет и о других библиотеках, то у DbSimple мне, кстати, описание (зачем еще одна библиотека) понравилось, но сам не пользовался. Кроме того, есть всякие билдеры, которые упрощают поддержку кода.

Спасибо конечно за развернутый ответ, но я имел ввиду именно "Защиту от SQL инекций". Т.е. как я понял, ТС пишет код в процедурном стиле, какой смысл ему создавать отдельный объект и защищаться от инъекций с средствами PDO? Конечно, если бы у него все было в ОО-стиле, то да, смысл может и был бы (чисто ради соблюдения общего стиля кода).

ты как-то все в кучу смешал. pdo в плане sql-инъекций просто решает часть вопросов за тебя. Т.е. это проще, потому что нужно меньше знать, и это проще, потому что часть служебной логики спрятана в pdo, следовательно легче просмотривать код. Но это была далеко не единственная цель pdo и pdo - не надстройка над расширением mysql, поэтому интерфейс получился сложнее, чем мог бы быть

А то что pdo построено на классах... какая разница? Mysql (расширение) тоже неявно построено на классах. И если язык позволяет использовать ООП, почему его не использовать? В моем понимании, ООП - это продолжение и синтаксический сахар для процедурного программирования. Т.е. не имея возможности использовать соответствующие синтаксические конструкции, ты все равно прийдешь к чему-то классоподобному. Другими словами, ООП способствует несколько другому, более удобному взгляду на программу. Наверное, как когда-то появление функций/процедур/подпрограмм поспособствовало. Хотя при этом оно может провоцировать возникновение ненужных слоев абстракции, или не всегда нужных. Но где ты видел палку об одном конце?

Довольно спорное утверждение...
Ну да ладно, твою точку зрения понял, выводы сделал. Спасибо за разъяснения.

вы не заметили что ответ на вопрос был дан ещё на первой странице и дальнейшее обсуждение автору тему не надо?

из мухи сделали слона :-E

Повторюсь, на всякий случай, идея в том, что когда ты прячешь реализацию с целью показать намерения, становится меньше деталей. Следовательно это проще воспринимать. И не надо знать реализацию. А в чем спорность?

с чего ты взял, что автору оно не надо? Да и даже если автору не надо, может еще кому-нибудь пригодится