index0h

Не защитит

Elasticsearch с морфологией вам в помощь.

нужно ли тут проверять пустые ли переменные???

Этот подход считается довольно геморным, но он колоссально экономит время при отладке. Так что да, это стоит делать.

Что касается глобальных переменных - лучше их не использовать.

Используйте raw sql и не мучайтесь.

1. открываете транзакцию
2. записываете в одну таблицу
3. записываете в другую таблицу
4. коммитите транзакцию

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

Лично я работал со следующими связками:
- Vagrant + bash provisioning
Этот способ с самым низким погором вхождения, но он очень требователен к качеству кода И процесса установки и обновления.

- Vagrant + ansible provisioning
Этот способ по сути включает в себя bash provisioning, но в структуре ansible. Работая в команде будьте готовы к тому, что провизионирование далеко не у всех будет нормально работать и это будет источником вашей головной боли. Если базово подтянуть bash у сотрудников еще не вызовет вопросов, то с ansible это процесс будет сложнее.

- Docker
Чистый докер требует далеко не маленькой компетенции. В команде я бы настоятельно не рекомендовал его использовать без дополнительных обвязок. По сути вам прийдется сделать свой docker-compose.

- Docker + docker-compose
Считаю оптимальным решением для dev окружения при работе как в команде, так и без.

https://ru.m.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BB...

Если это вопрос, что именно у вас не получается?
Если это задание, вам на фриланс биржи.

Начните с синтаксиса php, а потом беритесь за фреймворки

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

И не костыльте с assert

Что-то у вас за 5-6 лет стажа вопросы все чудесатей и чудесатей.

Смотрите ещё, если я поменяю массив password в низ, то email будет работать, а пароль нет, ахахаа, че за духи?

Это не духи, это незнание синтаксиса. У вас происходит выход (return) из метода validation (лучше используйте глаголы в названиях) после первой проверки required.

Странно, что у вас message фактически является rule, что как бы не верно.

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

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

Подскажите, как сделать правильное сравнение дат, проверить входит текущая дата во временной интервал или нет.

1. Преобразовать даты к числовому виду (UNIX timestamp)
2. Сравнить с начальным timestamp и конечным timestamp

Вы для JOIN условие забыли. JOIN *** ON ***

Ваш иcходный вариант оптимален. Вызов http_build_query вводит в заблуждение, так как у вас строка не имеет ничего общего с http query.

phpStorm