jazzus, а кто запрещал? Попробуйте.
Но в документации: "Все условия (времени запуска) проверяются по «логическому И», кроме условий «день недели» и «день месяца» — указанные совместно, они обрабатываются по «логическому ИЛИ»"
Каждый понедельник в 4:00 через крон будет что-то вроде 0 4 * * 1.
Далее в строке запуска сделайте проверку номера недели на четность, что-то вроде
[ $[$(date +"%U")%2] -eq 0 ] && ...
blantcat, конечно, решение с EAV и разделением на типы позволит индексировать по полям типов и делать за счёт этого более производительные выборки по условиям с атрибутами. Но вы действительно хотите все оптимизировать только для этого? Формируя запрос вам нужно будет динамически выбирать поле исходя из типа данных, если захотите получить сущность со всеми атрибутами одной строкой придется разворачивать таблицу, а это очень затратно. Поэтому выбирайте этот вариант, если только уверены, что подобная оптимизация крайне необходима, т.е. неоптимальная работа других выборок не так страшна и нет возможности делать выборки иначе.
Валентин, поверю, некомпетентных руководителей видел много, особенно тех, кто занимается некой "своей" работой, а что такое управление персоналом не представляют. А просранные сроки, неорганизованность сваливают на своих работников, у которых "низкая скорость работы".
Обычно это проходит с опытом, но некоторые так и продолжают лезть в работу своих сотрудников, считая себя самыми компетентными во всем и вся,
сводя общую производительность к нулю, таких уже не останавливает ничего, кроме увольнения.
EAV это очень плохой вариант хранения данных, разделение на типы по большому счету бессмысленно, а производительность будет дико теряться на pivot. Поэтому выбирайте этот тип только в том случае, когда остальные варианты не подходят.
Если атрибутов не может быть больше 7, то зачем вам EAV? Но, только, если их действительно, физически, не может быть больше.
В общем случае, я бы тоже выбрал jsonb, даже если вам нужно выбирать эти параметры из базы по-отдельности.
netyshka, я заметил, что вы на корректную конструкцию написали следующее:
Андрей, никто не написал, что он не будет работать, он работает неверно. а врубив в веркбенче например написание правильного синтаксиса , то он просто не выполнится
Эта фраза в корне неверна и может кого-то ввести в заблуждение.
А насчёт идиотского синтаксиса MySQL допускающего неявные вещи при использовании group by никто не спорит.
netyshka, это и есть SQL, диалект MySQL. Чистый SQL, без особенностей конкретной СУБД, в реальном большом проекте не встречается, слишком много отличий даже в простых вещах.
И надо использовать именно агрегирующую функцию min. Во-первых потому что это логично и легко читаемо, во-вторых это более производительное решение. С построенным индексом разницы, конечно, не будет, но без него, разница будет очень существенной, т.к. наложение одной агрегатной функции гораздо более лёгкая операция, чем сортировка.
ItWheel, выше у вас написано, что вам нужно что-то модное молодежное, и ни цели, ни задачи нет. Тогда, как уже написал, берите любой из предложенных инструментов, разницы нет. Вы не сможете ошибиться в выборе, т.к. нет задачи и нет цели, нет критериев оценки.
ItWheel, нужна задача, именно с нее начинают и для решения задачи подбирают инструменты. Подбирать инструменты для инструментов тоже можно, но решит ли это задачу неизвестно. Различных инструментов уже поднакидали в ответах, выбрать можно любой по душе. В фреймворке нет особого смысла, т.к. вы не предполагаете использовать его функционал.
Константин Цветков, Илья, так это big data, тогда забудьте, что я написал, то касалось реляционных СУБД, здесь работайте как с big data, разделяете на стадии и распараллеливайте работу.
maerio, замечу ко всему перечисленному, что MVC, это схема разделения данных, а не шаблон структуры. Поэтому даже применяя MVC, структуру нужно будет продумывать, исходя из того что это API, версионности и других только вам известных аспектов.
Postman очень простой, регистрироваться не обязательно, ограничения есть, но не помню чтобы они сильно мешали. Поэтому больше зависит от ваших предпочтений, а их никто кроме вас не знает.
Илья, не важно большая или нет БД, вопрос в том, что можно вам с ней делать. Производительность ниоткуда не возьмётся, очевидно в вашем варианте теряем на преобразовании функцией, и от него нужно избавиться, поэтому что-то все равно придется создать - новый столбец, индекс или таблицу связей.
