Стоит ли добавлять index для полей таблицы EAV?

Akina,

Можно вообще закэшить статические таблицы, создав копию с ENGINE = Memory, только там создавать индексы, и поплёвывать на производительность дисковой подсистемы. А изменения класть обратно триггерами.

А что это даст? Кроме того, что экономим место на диске для индексов, но имеем тяжелый "холодный" запуск во время которого будут создаваться эти индексы в таблице в памяти.
При этом просто любая таблица с индексами и так будет в памяти во время работы и читать ее с диска нет нужды. Конечно, при условии что достаточный buffer pool.
Смысл наверное только для тяжелых таблиц, которые читаем раз в год, и в добавок buffer pool ограничен, так что вытеснение ее из памяти при обычном хранении вполне реально. Но, это чтото очень экзотичное.

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

tukreb, то был риторический вопрос, не знал что yii3 может, спасибо, надо будет на него посмотреть

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

Sanes,

не на Симфони, а на его компонентах. Немного разное. Тоже самое, что построить на произвольных библиотеках из композер.

А получится ли также использовать произвольные компоненты yii, не затянув при этом весь фреймворк?

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

Sanes, именно так, в нем нет больше необходимости, можно просто настраивать Symfony как микро или как макро.

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

Sanes, я бы не назвал symfony микрофреймворком - это просто фреймворк с нормальной архитектурой. Потому что, авторы знали что высокий coupling - это плохо, и имели достаточно времени чтобы решить все эти вопросы, обеспечив независимость компонентов.
И, да, более универсальное решение чаще всего будет сложнее в освоении, чем специализированное.
А что выбирать, это всегда вопрос возможностей и потребностей.

Какой 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, не говорю, что одна или другая лучше, они для разных задач. Но вы не правильно описываете вариант, не должна каждая точка знать все обо всех, она получает сообщение и делает действие, а решать кто должен получить это сообщение, а кто нет будет уже другой объект, в компетенции которого будет как раз принятие таких решений.