FanatPHP

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

Суровая же правда жизни заключается в том, что сломаться может любой код. Хуже того - обязательно рано или поздно сломается. И поэтому надо не искать волшебный Правильный код, а учиться разбираться, почему не работает то что есть.

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

Для начала открой исходник хтмл выводимой страницы и посмотри, нет ли записей там.

вместо

$mysql = new mysqli('localhost', 'root', '', 'factotum_base');

if ($mysql) {
 	echo ":)";
 } else {
  echo ":(";
 }

Написать

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$mysql = new mysqli('localhost', 'root', '', 'factotum_base');

А этот ужас

if ($res == false) {
    printf("Ошибка при выполнении запроса\n");   //вылетает ошибка :(
  } else {
    printf("Запрос выполнен :)");
  }

убрать целиком

Первая

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

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

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

Но вот код, который лежит внутри catch(OrderException $ex){ является избыточным. Логирование ошибки и вывод стандартного сообщения клиенту - это то, что должен делать централизованный обработчик ошибок, который в любом случае должен присутствовать в приложении. То есть здесь этот код явно лишний.

Если запросы идут пачками в рамках одного и того же скрипта, то идеальным решением будет использование транзакций.
Если заворачивать пачку DML запросов в транзакцию, то производительность иннодб становится вровень с майисам. А в данном случае нам важно что достигается эффект отложенной записи, поскольку результат записи нас интересует для всей транзакции, а не для отдельного запроса, а БД достаточно умна чтобы флушить данные на диск пачками. И в итоге все летает и диски не напрягаются даже при дефолтной настройке innodb_flush_log_at_trx_commit

Тебе ещё рано браться за такие сложные задачи.
Повторяй пока выполнение запроса SELECT из РНР.
А оператор LIMIT проходят в следующем классе.

пишешь в адресной строке своего браузера, PHP ЧПУ

А простая идея сравнить исходную строку с полученной не приходила в голову?

нужно ее декодировать с помощью функции urldecode().

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

И надо не раскодировать данные, а убирать лишнее кодирование.

Ну, как бы, в наличии "слеша" и заключается вся разница.
Как говорится в одном древнем тексте,

Это не просто палочка, а самостоятельный АДРЕС, путь.
В адресе www.site.ru/ последняя косая черта - не для красоты! Она обозначает вполне конкретный адрес - начало сайта.

Если ты вдруг выведешь REQUEST_URI не при обращении к корню сайта, то сразу увидишь разницу

Возможно, тебе будет интересно узнать, что опечатка в переменнй $fistname - это наименьшая проблема в твоем коде. В нем кривая каждая строчка, за исключением, пожалуй, первых четырех. Хотя нет, они тоже неправилные. Вместо них должен быть инклюд.

А проверять наличие переменной не нужно. Переменная в посте всегда есть. Если надо проверить на пустоту, то это делается совсем другими функциями.

Генери заранее только самую большую из превьюшек. на будет заведомом меньше монстра 5000х5000 и из нее првеьюшки будут генериться куда быстрее чем из исходной

вместо гд можно еше использовать имеджик - он покачественнее, пошустрее и поумнее

В рамках данного метода - никак.

Чтобы подставлять имя таблицы в запрос, надо будет по настоящему учить ООП, и писать настоящие классы, а не то что у тебя сейчас - обычная функция, которой класс по сути не нужен.

Если никто не соберется прочесть вопрос и написать нормальный ответ, я попробую найти время в выходные и доделать статью, где объясняется, как это делать правильно

Нужно. mysqli_num_rows() - абсолютно бессмысленная функция. Которая отсутствует в других апи, в силу своей ненужности. И везде, где она применяется, можно обойтись без неё.

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

Руки конечно отрывать надо таким видеоучителям.
Весь код здесь - это ад кромешный, и выучиться по нему можно только на никому не нужного говнокодера.

Но к проблеме это отношения не имеет.
Тут либо опечатка в имени БД, либо на компьютере стоит 2 базы данных
Чтобы убедиться в первом надо написать

$pdo = new PDO("mysql:host=$host", $user, $pass);
$dbs = $pdo->query('SHOW DATABASES')->fetchAll();
var_dump($dbs);

и посмотреть что выведет

я новичок, и пока не понимаю как это можно организовать.

Ничего страшного, это нормально.
Все мы учимся.
Просто не пытайся пригнуть выше головы, ставь себе посильные задачи. А эту отложи на потом.