FanatPHP

site:toster.ru  Как выполнить запрос через прокси в php?

- скрпируй этот текст в адресную строку своего браузера и нажми Ентер.

context должен быть строкой, а не массивом.

Не лез бы ты в абстрактные классы пока.

А если по теме, то тебе же ведь уже раз 5 объясняли как пользоваться твоим собственным классом БД

$sql = 'UPDATE `' . static::getTableName() . '` SET `views` = `views` +1 WHERE id=?';
return $db->query($sql, [$article->id]);

Подставлять надо не урл, а найденный выше id

Вообще можно. Но обычно не нужно.
В приведенном же примере это какая-то бессмыслица.
Вместо вопроса "можно ли экранировать" надо задать вопрос "мне нужно сделать то-то, как это делается"?

Lost in translation.
В оригинале ничего, естественно, про именованные параметры нет

Yii2 - это фреймворк, условно говоря, второго поколения - Codeigniter, Kohana, ZF1.
Инструмент для стиля фигак-фигак - и в продакшен.

Начинать на нем что-либо будет недальновидно. Если осваивать Yii, то 3 версию, которая уже ближе к третьему поколению фреймворков, которое в первую очередь характеризуется модульностью и слабой связанностью.

Но полезнее всего работать с Симфони.

Потому что у тебя в коде написано выводить на экран.

Если ты сам код писал, то просто убери везде try catch или проверку на ошибку запроса.

Если не сам, то просто выкини и найди нормальный.

С третьей попытки осилим дописать этот черезвычайно сложный код

$sql = 'SELECT * FROM `tasks` WHERE `id`= :id' ; // запрос вроде бы правильный
$query = $pdo->prepare($sql);
$query->execute(['id' => $id]); // а выполнить забыли
echo json_encode($query->fetchAll(PDO::FETCH_OBJ)); // ой, а while оказывается не нужно!

как проверить массив на наличие в нем элементов

Не поверишь, if ($feedback)

<?php if ($feedback): ?>
            <?php foreach($feedback as $post): setup_postdata($post) ?>
            <?php endforeach ?>
    <?php else ?>
No reviews found
    <?php endif ?>

Если делать по-человечески

$stmt->$mysql->prepare("UPDATE applications SET closed=1, close_user=? WHERE id = ?");
$stmt->bind_param("ss",$close_user,$id);
$stmt->execute();

order deny,allow
deny from all
allow from <your ip>

Но вообще, класть файлы, которые "никто не должен видеть" на дешевый шаред хостинг - это очень, очень богатая идея

Я думаю здесь подмена понятий. Автор пишет "кэширует ли БД запросы", а имеет в виду "может ли в принципе эта страшная и непонятная громадина которая называется базой данных в принципе хоть когда-нибудь рабтотать быстро?"
Все, разумеется, кидаются отвечать на первый вопрос.
А на самом деле надо отвечать на второй. Да, почти всегда БД работает гораздо быстрее чем ты можешь вообразить и ничего кэшировать не нужно. Если вдруг стало работать медленно... впрочем, об этом ниже.

Нужно ли делать кеширование запросов
Вот в такой формулировке, взятой с потолка, "а не закэшировать ли мне запросы к базе данных*" - Нет, не нужно.

и как?
Очень просто.
Три простых шага:
1. Понять, устраивает ли тебя производительность приложения. Если устраивает, то все оставить как есть.
2. Если не устраивает, освоить профайлинг. Если это слово не упоминается в вопросе про производительность или кэширование, то вопрос можно сразу удалять. потому что он заведомо взят с потолка и не имеет смысла. По сути, профайлинг - это замер скорости выполнения отдельных участков кода для поиска узких мест - т.е. таких участков кода, которые тормозят всю программу. Это можно делать и вручную, и с помощью различных готовых инструментов. Только по результатам профайлинга, который показал конкретную причину тормозов, то самое узкое место (его еще называют bottleneck, "бутылочное горлышко"), можно приступать к оптимизации. Не кэшированию!
3. Если профайлинг показал, что проблема в конкретном запросе к БД, приступаем к его оптимизации. Чаще всего достаточно добавить индекс или донастроить сервер.
4. Только если все другие способы не помогли - занимаемся кэшированием. Но перед этим сначала решаем Вторую Важнейшую Проблему Информационных Технологий - инвалидации кэша. Поскольку закэшировать - это ерунда, каждый дурак сможет. Самая главная проблема не в том, как данные положить в кэш, а как и когда их оттуда удалять.

Это просто идеальная иллюстрация к известному высказыванию Дональда Кнута "Преждевременная оптимизация - корень всех зол".

Сначала высасываем из пальца проблему: "тратится время на обращение к бд". Сколько там его тратится, тратится ли вообще, замедляет ли это систему, является ли вообще это проблемой - все эти вопросы нам неинтересны. Мы хотим грудью на амбразуру, стать героем и получить медальку.

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

Стоит ли так делать и почему;
не стоит потому что не надо высасывать проблемы из пальца.
Какой будет прирост производительности
Отрицательный
Как Вы решаете подобные вопросы.
МЫ ИХ НЕ РЕШАЕМ.
Мы решаем реальные проблемы, объективно существующие.
А воображаемые проблемы высосанные из пальца решать не следует.

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

Если отвечтаь на вопрос буквально, то

1. Для большинства простых операций с БД запросы вообще не пишутся, пишутся обращения к ORM. Например в вместо

$stmt = $pdo->prepare("SELECT * FROM users WHERE id=?");
$stmt->execute([$id]);
$user = $stmt->fetch();

Пишется

$user = $em->getRepository(User::class)->find($id);

2. Сложные запросы с фильтрами лежат в специальных классах, которые называются репозиториями.