Какие варианты могут быть при рандомной невозможности системой увидеть рут-раздел при загрузке?

На всякий случай, проверьте как выбирается загрузочный диск, если по имени /dev/nvme0n1p2, попробуйте поменять на UUID

Почему PHP так сравнивает строку и число?

Константин,

Строгое сравнение не вариант. В том же массиве у меня сравнение, например
string("0.5") == float(0.5)
И тут я должен получить true, а при строгом сравнении буду получать false

Ах вот зачем эта наркомания! Как всегда, вместо того, чтобы написать стабильный понятный код, мы пишем невесть что, пытаясь съэкономить 2 строчки, т.к. так "красивее и производительней".
Через месяц вы уже не будете понимать, что за бессмыслица была написана. Тесты, разумеется, тоже писаться не будут. Все варианты типов тоже никто не будет проверять. Со всеми отсюда вытекающими.

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

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

Akina, допустим, но какой смысл этой таблицы в памяти? Любая таблица всегда помещается в память, зачем эти манипуляции?

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

mayton2019, именно так, просто фраза выше реально звучит как "серебряная пуля". Действительно, надо исходить из того, как данные будут использоваться. Если плевать на производительность, нет проблем - json. Если не работаем с большими таблицами - тоже да. Причем данных может быть много, но, например, мы так удачно расшардировались, что даже при фильтрации по внутренностям json нам надо пробежать только 1 маленький шард. А если таблица большая и нам важны милисекунды, то выносить из json в отдельные поля и индексировать.

Ошибка: You have an error in your SQL syntax?

В какой документации? Явно не в доке по MariaDB https://mariadb.com/kb/en/grant/

Стоит ли добавлять 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, если вдруг не только в отелях начнут людей собирать.