Защита от SQL инекций

[Gozar]

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

[Invis1ble]

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

[x-yuri]

Какой аргументации? помоему, все очевидно - ненужный вызов лишней функции.

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

Я так понял, что ТС не использует никаких фреймворков, что же ему делать? Ради "удобства" (что спорно) составления запросов добавить к своему коду в 100500 раз больше мертвого кода, 99.99% которого он никогда не использует?

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

Ну да, ну да. А раз мы пишем на php, значит можно написать "надстройку", а потом еще одну, ну и снизить производительность в итоге раз в 50. Зато "удобно" !

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

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

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

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

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

[Invis1ble]

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

[x-yuri]

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

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

[Invis1ble]

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

[x-yuri]

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

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

[Invis1ble]

Т.е. это проще, потому что нужно меньше знать, и это проще, потому что часть служебной логики спрятана в pdo, следовательно легче просмотривать код.

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

[evgh]

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

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

[x-yuri]

Т.е. это проще, потому что нужно меньше знать, и это проще, потому что часть служебной логики спрятана в pdo, следовательно легче просмотривать код.

Довольно спорное утверждение...

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

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

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