Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: PDO: prepare или прямые запросы в простых SELECT-ах? [2]
Форумы портала PHP.SU » » Вопросы новичков » PDO: prepare или прямые запросы в простых SELECT-ах?

Страниц (2): « 1 [2]
 

16. esterio - 28 Мая, 2014 - 12:35:51 - перейти к сообщению
caballero пишет:
prepare не имеет никого отношения к биндингу параметров. Это разные ничем не связанные вещи.

ну почему же совсем
PHP:
скопировать код в буфер обмена
  1. if ($stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=?")) {
  2.  
  3.     /* связываем параметры с метками */
  4.     $stmt->bind_param("s", $city);
  5.  
  6.     /* запускаем запрос */
  7.     $stmt->execute();
  8.  
  9.     /* связываем переменные с результатами запроса */
  10.     $stmt->bind_result($district);
  11.  
  12.     /* получаем значения */
  13.     $stmt->fetch();
  14.  
  15.     printf("%s находится в округе %s\n", $city, $district);
  16.  
  17.     /* закрываем запрос */
  18.     $stmt->close();
  19. }

Как видно там явно видно биндинг параметров
P.S. взято из офф докы дабы не придумивать пример.
17. OrmaJever - 28 Мая, 2014 - 12:43:18 - перейти к сообщению
caballero пишет:
prepare не имеет никого отношения к биндингу параметров

prepare statment это подготовленные запросы,
подготовленные запросы это когда в нем есть динамические части тобиш ? (where id = ?),
Если есть ? то на них нужно назначить некоторое значение,
Как? bind_param.

По-моему писать
PHP:
скопировать код в буфер обмена
  1. $p = $mysqli->prepare("SELECT * FROM `table`");
  2. $p->execute();

смысла никакого не имеет, поэтому лично для меня prepare ассоциируются с bind_param.
18. DelphinPRO - 28 Мая, 2014 - 14:04:21 - перейти к сообщению
в начале года делал проект. нужно было раз в сутки заносить в БД большие объемы статистических данных (я вроде даже тему тут создавал). Провел опыты с использованием PDO.
Были варианты
1. отдельные INSERT запросы
2. подготовленные запросы
3. объединенный INSERT INTO () ... VALUES ((...),(...),(...))

Первый как и ожидалось слишком медленный.
А вот второй оказался медленнее третьего.

Что касается одиночных запросов, не вижу особой разницы. Использую prepare из-за удобства.
Как говорит caballero - когда придет время писать высоконагруженные проекты, у программиста уже не будут возникать подобные вопросы. (или как-то так) Улыбка
19. esterio - 28 Мая, 2014 - 14:05:43 - перейти к сообщению
DelphinPRO пишет:
ак говорит caballero - когда придет время писать высоконагруженные проекты, у программиста уже не будут возникать подобные вопросы

Плюсую. А за статистику отдельно спасибо
20. caballero - 28 Мая, 2014 - 14:11:46 - перейти к сообщению
Цитата:
смысла никакого не имеет

кенешно не имеет - prepared предназначен для много кратного почвтороения того же запроса, возможно с разными параметрами. но на практике выиграша по скорости все равно особо нет - выборка данных все равно занимает больше времени чем компиляция запроса. может лет 30 -40 назад смысл был
21. LIME - 28 Мая, 2014 - 14:16:35 - перейти к сообщению
teddy пишет:
'Двадцать тысяч символов'
ну допустим
но все равно это синтетика
часто бывает необходимость сохранять такие рукописи? еще реже они приходят от пользователей наверное
и гораааздо реже случаи когда такие запросы случаются настолько часто что отказ от экранирования повлияет на что-то
ни дай боже столкнуться с таким проектом)))
удобство да...гарантия от инъекции да...не более
22. teddy - 28 Мая, 2014 - 14:33:49 - перейти к сообщению
LIME пишет:
но все равно это синтетика

От части я согласен. Но с другой стороны представь что у тебя огромный проект где юзеры долбят БД инсертами миллион раз в секунду(образно) сообщениями различной длины или любую другую вставку где у тебя экранируется 5 значений одновременно. Ты пять раз вызовешь экранирующий метод а я нет. 5 раз вызовется метод при обращении Васей для инсерта, Пять раз Петя, 1 000 000 * 5 === вызов пять лямов раз одной функции в секунду + парсинг данных которые мы ей подсунули + увеличится затрата времени на синтаксический анализ кода ввиду того что кода стало больше.

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

Все это конечно в теории и делая запросы на локалхосте без реальной нагрузки сложно что то сказать, но несмотря на это я все же выкинул обычный query и сделал выбор в пользу подготовленных запросов. Причины уже писал и на этой и на прерыдущей странице )
23. LIME - 28 Мая, 2014 - 14:36:02 - перейти к сообщению
teddy пишет:
пять лямов раз одной функции в секунду
или пять лямов отправки запроса на подготовку
что гораздо накладнее
24. Anchor - 28 Мая, 2014 - 14:37:43 - перейти к сообщению
Нашел интересную статью, как раз на эту тему http://habrahabr[dot]ru/post/149613/

Повторюсь, задавал вопрос Улыбка :

Anchor пишет:
Каков принцип работы плейсхолдеров? Я понимаю, если происходит подстановка строковых параметров. Тогда, да, как понимаю, там этот параметр, вылижут, отэкранируют, проверят, и пр. Со строковыми параметрами - безусловно удобнее.

Но: не могу понять, в данном, конкретном случае:

CODE (SQL):
скопировать код в буфер обмена
  1. 'SELECT * FROM table WHERE id=:id LIMIT 1'

Могу же я сделать, просто так:


Ведь 100% знаю, что $item_id теперь пролезет только ЧИСЛОВОЙ. Или все же есть нюансы и здесь?
25. LIME - 28 Мая, 2014 - 14:38:55 - перейти к сообщению
Anchor пишет:
Или все же есть нюансы и здесь?
есть
рано или поздно забудешь валидировать/фильтровать
(Добавление)
и кстати плейсхолдеры не отменяют валидацию
26. teddy - 28 Мая, 2014 - 14:48:22 - перейти к сообщению
LIME
Я не DBA поэтому не могу точно ответить на этот вопрос особенно потому что я мало знаком с хитростями производительности БД за исключением банальных подходов. Опять же скажу все это в теории - на практике я ещё не успел все это пощупать.

Anchor пишет:
Ведь 100% знаю, что $item_id теперь пролезет только ЧИСЛОВОЙ. Или все же есть нюансы и здесь?

При биндинге параметров можно явно указывать тип передаваемого значения
27. LIME - 28 Мая, 2014 - 14:55:04 - перейти к сообщению
teddy пишет:
При биндинге параметров можно явно указывать тип передаваемого значения
а хотелось бы еще и границы значений например
это можно без ручной валидации?
28. teddy - 28 Мая, 2014 - 16:16:30 - перейти к сообщению
LIME пишет:
или пять лямов отправки запроса на подготовку

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

LIME пишет:
это можно без ручной валидации?

Я упомянул про возможность задать явный тип передаваемого значения но не про полноценную валидацию сервером с возвратом ошибок для клиента

Вообще я думаю превращать этот разговор в большую дискуссию нет смысла хотя бы потому что в конечном счете решение относительно того как "оформить" тот или иной кусок кода/операцию решается исходя из самой задачи и нет единого решения на все случаи жизни.
29. Anchor - 29 Мая, 2014 - 14:37:23 - перейти к сообщению
LIME пишет:
Anchor пишет:
Ведь 100% знаю, что $item_id теперь пролезет только ЧИСЛОВОЙ. Или все же есть нюансы и здесь?
есть
рано или поздно забудешь валидировать/фильтровать
(Добавление)
и кстати плейсхолдеры не отменяют валидацию

Т.е. дело просто в стиле(в данном случае)? Мол просто привыкать так писать везде (бинды)

(Добавление)
teddy пишет:
При биндинге параметров можно явно указывать тип передаваемого значения

Угу, thanks!
30. LIME - 29 Мая, 2014 - 14:39:36 - перейти к сообщению
не в стиле а в гарантии не пропустить инъекцию

 

Powered by ExBB FM 1.0 RC1