mkone112, любовь к одному направлению должна перерастать в опыт, а любитель - в профессионала, которому в шарашке, где требуется спец "все в одном" просто тесно. Вопрос все-таки про "маленькие компании", где все делают всё, если понадобилось.
Akina, разумеется. Только с этими данными она будет связана очень косвенно.
Потому что в календаре нет отгулов и сверхурочных - только рабочие дни, выходные и, возможно, рабочие выходные.
И дата в этой таблице будет уникальным значением, так что практической разницы, связываться с ней по айдишнику записи или просто по дате, нет. С айдишником могут возникнуть проблемы типа попытки занести сотруднику декретный отпуск на три года вперед при том, что производственного календаря на эти годы еще нет.
Akina, так производственный календарь с праздниками и прочими атрибутами, не касающимися каждого работника по отдельности - это совсем другая сущность.
Тут-то рабочий график, именно индивидуальные даты. Вплоть до "явился на смену пьяным, ставим прогул" и "вышел на пару дней из отпуска по производственной необходимости". Такие данные отрывать от работника бессмысленно.
Akina, насчет полностью - это вы ТС-а спрашиваете. Я, собственно, по собственному опыту хранения рабочих графиков отписываюсь.
Имхо, нормальнее плоской таблицы юзер-дата-тип просто некуда.
Выделение дат с типами куда-то отдельно от юзеров просто не имеет смысла, они отдельно никому не понадобятся.
А смысл дробить эту инфу на две таблицы? Чтобы практически при любом запросе джойнить?
Если уж мудрить, так наоборот - привести дату с типом к одному значению вроде 2021083103, храня в последних двух цифрах код типа дня. Возможности сравнения и выборки сохранятся... но это тоже скорее фантазия, чем реальное предложение.
Как говорил классик, "Вам - везде!"
Неужели ЛЮБОЙ запрос на тему не выдает на первой-второй странице Php.net для базы и PhpTheRightWay для общего развития?
Этим людям просто некуда девать машинное время и ресурсы пользователя.
То, для чего давно сделан и отлажен ImageMagick, они делают жаваскриптом!
Но и этого им мало - они, [skipped], еще вынуждают посетителя выкачать ВСЮ pdf-ку с сервера только для того, чтобы показать ему, [skipped], превьюшку первой странички!!!
Вячеслав Правильный, так вы что защищаете-то? Запрос к вашему API (считать только тому, кто подтвердил, что это он) или валидность того, что оно отдает (заносить только то, что было рассчитано для этого сервера)?
FanatPHP, судя по бардаку в вопросе - и то, и другое %)
А если я прав насчет схемы работы, то еще и третье: сервер-сервер в обратную сторону (записи внешних пользователей - во внутреннюю систему).
FanatPHP, я так понял, это что-то вроде системы, в которой у каждой поликлиники свой сервер, но они на один общедоступный сайт валят расписание и запись к врачам. Прямо через открытый у оператора браузер. А на общедоступном сервере - голое API без всяких учеток (почему-то).
Тут в рамках защиты от подделки запроса разве что токен с клиента и обратный запрос к сервера к клиенту на подтверждение, что это он вошел с таким токеном.
