Valentine5, разделён - это когда СНАЧАЛА логика, а ПОТОМ html. А не как у вас - сначала HTML, потом прямо из него инклюдим логику, потом из логики выводим HTML, потом снова HTML.
Логика она на то и логика, что не должна ничего выводить сама. а только готовить сырые данные.
И только после того как данные подготвлены, они доджны выводиться.
А если этот скрипт должен будет возвращать json, а не html? При разделении логики и отображения, логику менять не придётся - только вывод. А у вас все перемешано
no_one_safe, же-же
во-первых, этот вариант более гибкий. В него можно, например, ввести нумерацию или особую разметку.
а во-вторых, и в главных - я не пытаюсь предложить решение этой "проблемы" (она слишком тупая для этого). Я хочу чтобы человек хоть немного продвинулся в понимании того, как работает непонятная штука под названием цикл. И мог в дальнейшем применять осознанно.
Владимир Егудин, в данном случае выигрыша нет, но просто порядок должен быть. если хотим поймать только исключение mysqli, то и его надо ловить.
"при тестировании мне так было удобнее" - это глупость какая-то. throw $e; делает ровно то же самое, плюс выводит больше полезной информации, которая и нужна при тестировании. Ну и в целом непонятно, зачем писать две версии кода, одну для тестирования, а вторую для прода.
можно код писать используя лишь query, используя следующие запросы:
PREPARE stmt FROM 'SELECT ....
Можно, но не нужно.
же вы относительно защиты от sql-инъекций - то она реализована на другом уровне.
Ну в теории это конечно возможно. Но на практике обычно такая реализация наполовину состоит из суеверий а наполовину - из супер-современных мануалов конца прошлого века. И дырявая на все стороны.
Впрочем, если уж используется "защита на другом уровне" и демон, то сам бог велел сделать пул подключений и использовать асинхронные запросы.
400к записей - это вообще ни о чём. Даже без индексов всё должно летать.
Тут похоже хостер одновременно и говно и жулик. Даёт тухлое железо, на котором БД еле тащится (как вариант mysql - криво настроена и innodb buffer тупо не использует имеющуюся память) и тут же пытается подпихнуть ненужную услугу
Впрочем, сама ошибка на редкость дурацкая, и по идее легко исправимая. Но никто, разумеется, не удосужился её прочитать.
Владимир Егудин, хороший вариант. Но чисто для информации, на будущее:
собаку надо убрать, она тут явно ни к селу ни к городу
ловить лучше \mysqli_sql_exception
вместо die должно быть throw $e;
ну и подготовленные запросы надо потихоньку осваивать
Увы, это невозможно. Те, кто модерируют этот ресурс, ещё хуже тех, кто буллит. Там совсем всё плохо. Трафик падает, а они всё ищут, как бы поэффективнее повыгонять тех, кто еще сюда заходит
1. про классику вы явно не додумали. ну если только под "сущностями" не имеется в виду создание новых таблиц под каждый тип товара.
2. Это вообще непонятно к чему. Фреймворк понадобится для любого варианта, но вопрос-то был про структуру хранения
3. Это вариант, но его придется соединять с остальной базой. Поэтому, очевидное решение, это:
4. Обычная реляционная БД, где свойства товаров хранятся в формате "монги" - т.е. json. Это не такой простой в реализации (вот тут как раз и потребуется фреймворк) но наиболее жизнеспособный вариант
Если вы делаете запрос на свой же сервер, зачем вообще указывать хост и порт? А если завтра порт поменяется, то переписывать все запросы? Запрос делается с указанием только пути, /test/php.php
Как это понять?
Инструменты разработчика, вкладка Сеть. Там ВСЁ расписано. И получил ли РНР запрос, и какой именно запрос, и что именно ответил
Алексей Уколов вы бы хоть почитали комментарии. По-хорошему этот мусор надо целиком удалить, а не теги править. Потому что в таком виде к проблемам автора вопрос вообще уже никакого отношения не имеет, а половина ответов становятся бессмысленными, поскольку написаны про другую БД.
при том, что