FanatPHP

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

Не поверишь, 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. Сложные запросы с фильтрами лежат в специальных классах, которые называются репозиториями.

Ну если по простому, то

select * from images where position in (select min(position) from tests group by product_id);
select * from images where position not in (select min(position) from tests group by product_id);

Это какая-то дурацкая и бессмысленная функция. Не надо её вообще использовать.

$date  = DateTime::createFromFormat('d-m-Y',date('d-m-Y'));
$day   = $date->format('d');

Update table set field = md5(rand())

Ни в коем случае.
Твоя база данных не зря названа реляционной, то есть связанной. Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

И не надо слушать советчиков из соседних ответов.
Увы, поколение милленниалов не умеет воспринимать письменный текст, и реагирует в лучшем случае на пару ключевых слов в вопросе, не воспринимая корнтекст. Который, чтобы было понятно, звучит так: Нашел у папы в сарае заряженнвую двустволку. Прикладом очень удобно орехи колоть. Это удобнее потому что из щипцов орехи вываливаются. Нормально ли колоть орехи заряженным ружьем?

Сериализованные данные стоит хранить в бд только в очень крайнем случае.
На данном этапе вообще забудь про такую возможность и учись работать с БД правильно.