Какой PHP фреймворк выбрать для реализации REST API?

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

Вывод из бд данных и присваивание им значение?

ThunderCat,

Короче, ничуть не умаляя нужности енум как формата, требуется 10 раз подумать прежде чем его использовать

Абсолютно согласен.

В общем, насчет enum в СУБД, чтото у меня уверенность пропала, что это хорошая идея, т.к. не факт что даже понимая и принимая ограничения, ограничимся только DDL проблемами. Enum в приложении другое дело, это не очень привычно для php, но не для других языков. Я работал с типизированными enum еще до php8, и на мой взгляд это очень полезная вещь. Но, тут, вы правильно заметили, что нужно понимать что это и зачем вам нужно. И статья это хорошо показывает, что кто-то может ожидать от enum совсем иное, чем они являются.

Вывод из бд данных и присваивание им значение?

ThunderCat,

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

Число это такой же Enum, скажем tinyint это перечисление из 255 значений, которые строго определены, ничего кроме них выбрать нельзя. Поэтом когда автор статьи писал "если в дополнение к названию континента требуется сохранить его площадь", то это тоже самое как в tinyint захотеть "напихать" букв.

так как именно для этого и храним уже готовые варианты, а не для того чтобы еще делать враперы для данных на стороне ЯП.

Не совсем, даже если мы храним статус перечислением TO_DO и DONE, то даже на английском пользователю скорее всего выведем алиасы вида "To Do" "Done". Но, согласен, список все равно так или иначе потребуется, а парсить то, в каком виде это лежит в information_schema будет невесело.

Вывод из бд данных и присваивание им значение?

ThunderCat,

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

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

Ну и размазывание хранения по нескольким местам не лучшая идея.

Согласен, вероятно, если есть контроль в приложении, контроль на стороне БД принесет больше проблем (те же DDL), чем плюсов.

В принципе, проблемы +- те же. Кроме того что, по сути, они легко заменяются ассоциативными массивами, они еще накладывают ряд ограничений, например результаты нельзя сравнивать скалярно.

Главный смысл - это ограничение, не так важно будем ли мы использовать enum из php8, или самописный (здесь наверное больше константы подойдут, а не ассоциативный массив).
А сравнивать на больше/меньше это както очень странно, зачем? Зачем сравнивать true и false на больше/меньше? Или сравнивать пол? Как правильно написано в доке, это не имеет смысла, поэтому это ограничение только плюс, оно не позволит делать с Enum то, что делать не нужно.

Вывод из бд данных и присваивание им значение?

ThunderCat, что касается MySQL Enum

Enum очень специфичный формат хранения, с кучей недостатков и подводных камней.

выше указанная статья хоть и имеет целых 8 пунктов "Enum - зло", но большинство из них не выдерживает критики.

spoiler

1. С данные обращаются не как с данными
Чушь, техническое хранение данных не должно иметь и не имеет зависимости от его логического представления. Скажем тип boolean слова 'true' и 'false' тоже не хранит прямо в странице.

2. Изменение списка значений ENUM обходится дорого
Очень многие операции DDL в MySQL обходятся дорого. Если ваши таблицы огромны, то действительно стоит подумать использовать ли Enum. Но это не проблема Enum, а все тот же подход, когда мы отказываемся от контроля на стороне БД потому что так дешевле.

3. Невозможно добавить дополнительную информацию
Это не проблема Enum, это мы неправильно выбрали тип данных. Если вы назначили полю тип int, то очень странно удивляться, что туда не залезают буквы.
Тоже самое про "прекращение использования данного варианта", используя int тоже не так то просто "отменить" использование цифры, например 2. Подобная "отмена" это уже слишком сложная логика ее в тип данных не запихнуть.

4. Получение списка уникальных значений ENUM - боль
Это только кажется правильным, но подставлять значения прямо из БД не очень хороший вариант, мы и для boolean можем выводить true/false, но это просто ленивый подход.

5. Тип ENUM имеет весьма незначительный эффект в оптимизации
Все таки Enum в первую очередь это ограничение, поэтому, то что он быстрее это просто дополнительный плюс.

6. Нельзя использовать список ENUM в других таблицах
Сложно назвать это очень существенным недостатком.

7. Тип ENUM имеет много подводных камней
Да, мы привыкли к неявной типизации в MySQL, которая зачастую пораждает серьезные ошибки. Но, здесь с этим все ок, а вариант с Enum '0' '1' и путаницей значений и индексов выглядит надуманным.

8. Портирование ENUM в других СУБД ограничено
Портирование между СУБД всегда боль, т.к. в каждой СУБД множество специфики, поэтому расчитывать на легкое портирование хоть с Enum, хоть без - это странное ожидание.

Реальная проблема здесь только одна, очень ресурсоемкие DDL запросы. Но, тут ничего не поделаешь, MySQL работает только так, и если таблица огромна, то действительно можно хотя бы на Enum съэкономить.

Вывод из бд данных и присваивание им значение?

ThunderCat, вероятно вы правы, зря написал про базу. Но, какие есть проблемы в его использовании в php?

Вывод из бд данных и присваивание им значение?

значение от 1 до 6, ((пакетизация) 1- бан, 2- минимальный пакет и тд (так до 6))

Это называется Enum. Если СУБД умеет, то можно и в базе, но как минимум в php. Для, вывода используйте маппер, который пока будет отдавать просто значение Enum, но будет возможность в будущем поменять выводимые названия без переделывания Enum.

Как упростить примитивную тернарную логику?

вынесение функции в переменные не предлагать

Почему?

Как разбить таблицы?

Вопрос суррогатный vs натуральный ключ сложный, но в большинстве случаев лучше выбрать именно суррогатный. К примеру, если сделать натуральный ключ для регионов по его 2-3 буквенному ISO коду - отлично, а вот делать натуральный ключ по названию отеля очень сомнительный выбор, мало того что название может поменяться, так еще и делать ключ придется очень длинным и надеяться, что все названия в него поместятся, а потом еще и ссылки на него делать такими же. И скорее всего никто не будет искать по полному названию отеля, и тогда плюсы его как кластеризованного индекса сходят на нет.
Array, json и т.п. - это как правило нарушение нормализации, делать так нужно только тогда, когда понимаешь, что плюсы перевесят минусы. Т.е. в большинстве стандартных ситуаций это тоже не нужно.

Как разбить таблицы?

У вас даже в описании указано, что отель должен быть привязан к региону. И уж точно не к таблице связей.
Ну и на всяк случай, вместо hotel можно использовать start_location, если вдруг не только в отелях начнут людей собирать.

Какой инструмент применить чтобы избавиться от блокировки таблиц в БД, если доступ нужен по очереди?

Akina, надо еще не забыть: WHERE оператор is null. И разумеется не в рамках транзакции делать.

Блокировки никуда не денутся в этой схеме, но из-за простоты 1 запроса, все должно работать быстро и особых проблем не возникнет.
Вообще, даже если у автора сотни операторов на проекте, это не будет представляться проблемы во время работы, т.к. обращаться за заявками они будут в разное время. Но есть пиковый момент, когда операторы в ожидании и заявки поступают в обзвон. В этот момент все операторы ломятся на сервер за заявками, ктото успевает заблокировать 1 запись под update, остальные блокируются и ждут, update завершается, остальные получают ответ "приходите позже". Разумеется, эти запросы размазаны по времени, но чем больше операторов и чем медленнее СУБД, тем будет больше очередь. Кроме того, когда "вернулось ноль номеров", это может значит, что заявки закончились, тогда врубается пауза чтобы не кошмарить СУБД запросами, по истечении этой паузы все опять ломанутся за заявками, а из-за пауза ожидание увеличивается.
Повторюсь, из-за скорости работы одиночного update, все должно быть норм, но если нет, то можно паузу делать немного рандомной, либо проверять попал оператор на блокировку или действительно закончились заявки и в первом случае не ждать, а снова мучить сервер.
Теоретически, здесь хорошо подходит select for update skip locked - когда мы не ждем освобождения блокировки и уходим ни с чем, а просто берем следующую запись. Но нужно попробовать и убедится, что в конкретной СУБД все работает корректно.

Какой инструмент применить чтобы избавиться от блокировки таблиц в БД, если доступ нужен по очереди?

Оптимизируйте запрос, чтобы он выполнялся быстрее: добавьте соответствующие индексы, проверьте что транзакция открывается при самом запросе, а не где-то загодя. Вообще проверьте, что именно тормозит в выполнении транзакции. Почему транзакция блокирует таблицу? Почему всю таблицу? И почему вообще блокирует, какой у вас уровень изолированности транзакций?
С учетом "есть таблица заявок, которые обзванивают операторы", что-либо сложнее делать нет смысла, вряд ли у вас там высокая нагрузка.

Добавляются двойные кавычки в JSON ответе, как их убрать?

Не кодировать json еще раз в json

Не могу юзать namespace?

там не сказано, что php-код с namespace нужно вставлять в самый вверх html файла

Наоборот, именно это там и сказано, только не html, а php. Напомню у вас php скрипт, а не html

В чем минусы событийно ориентированного подхода?

Stalker_RED, не говорю, что одна или другая лучше, они для разных задач. Но вы не правильно описываете вариант, не должна каждая точка знать все обо всех, она получает сообщение и делает действие, а решать кто должен получить это сообщение, а кто нет будет уже другой объект, в компетенции которого будет как раз принятие таких решений.

В чем минусы событийно ориентированного подхода?

vitaly_74, сам факт - да. Но, одно дело, когда объект получает информацию что произошло событие: например, что подключился еще один пользователь, а "объект - счетчик подключений" реагирует инкрементируя внутреннюю переменную с кол-вом подключений. Другое дело, когда произошло тоже самое событие, и объект получает сообщение "инкрементируй счетчик". Т.е. он ввел понятие, что мы не манипулируем данными, скажем вызывая процедуру инкремента для переменной, которая принимает конкретный тип данных, а данные инкапсулированы в объект, который сам знает что делать, на основе сообщения в котором просьба провести инкремент счетчика. Это отличается от шаблона, когда subscriber получил только событие, а что он будет делать зависит от него. Если я, конечно, ничего не путаю.

В чем минусы событийно ориентированного подхода?

Насколько я помню, Алан Кей особо выделял что объекты взаимодействуют путем сообщений (message), а не реагируют на события (event). Т.е. объект получает информацию, не о том, что что-то произошло и реагирует на это, а получает предложение выполнить некое действие, а действие он выполняет исходя из того, каким объектом он является.

Почему эти значения равны в php?

Онотолий, неважно что говорю я, есть мануал, загляните в него:
https://www.php.net/manual/en/language.types.type-...
https://www.php.net/manual/en/language.operators.c...
'9 9' == 9
это сравнительный контекст, в котором в правой части число, а в левой части строка. Строка будет преобразована в число и получится 9. Сравнение 9 и 9 даст true.
Начиная с php8 будут использованы иные проверки и результат будет другой.

Как на PHP подготовить вставить HTML в JSON строку?

Сергей Кореневский,

А вообще странно то что функция json_encode() не хочет принимать строку.

Все там "дописано", в легкую принимает:

php > echo json_encode('q');
"q"

Как на PHP подготовить вставить HTML в JSON строку?

Сергей Кореневский,

Да у меня там JSON длинный. А создавать новый массив для сериализации как то не хочется.
Тем более это вопрос экранирования и очистки.

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