фидбек

[asundukov]

1. на messages отсутствует primary key - это несколько антипаттерн оставлять бизнесовую сущность без идентификатора - тогда мы не сможем манипулировать ей, например нельзя удалить конкретное сообщение т.к. если два сообщения будут содержать один текст и относить к одному response - то получим проблему

2. нейминг внешних ключей - в одном случае usr_id, в другом - vacancy_id . Стоит, разумеется, всегда придерживаться единого стайлинга, иначе создаешь проблему не только для чтения запросов глазами но и в будущем когда база сильно вырастет - будут проблемы с поиском нужных столбцов при написании новых запросов

3. active_days - очень спорное решение, получается его нужно обновлять ежедневно в 0-00,
   лучше в таких случаях использовать пару publish_start + publish_end с типом времени, либо просто publish_end если старт не нужен

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

[asundukov]

Да, теперь очень неплохо получилось!