Akina, так производственный календарь с праздниками и прочими атрибутами, не касающимися каждого работника по отдельности - это совсем другая сущность.
Тут-то рабочий график, именно индивидуальные даты. Вплоть до "явился на смену пьяным, ставим прогул" и "вышел на пару дней из отпуска по производственной необходимости". Такие данные отрывать от работника бессмысленно.
Akina, насчет полностью - это вы ТС-а спрашиваете. Я, собственно, по собственному опыту хранения рабочих графиков отписываюсь.
Имхо, нормальнее плоской таблицы юзер-дата-тип просто некуда.
Выделение дат с типами куда-то отдельно от юзеров просто не имеет смысла, они отдельно никому не понадобятся.
А смысл дробить эту инфу на две таблицы? Чтобы практически при любом запросе джойнить?
Если уж мудрить, так наоборот - привести дату с типом к одному значению вроде 2021083103, храня в последних двух цифрах код типа дня. Возможности сравнения и выборки сохранятся... но это тоже скорее фантазия, чем реальное предложение.
Как говорил классик, "Вам - везде!"
Неужели ЛЮБОЙ запрос на тему не выдает на первой-второй странице Php.net для базы и PhpTheRightWay для общего развития?
Этим людям просто некуда девать машинное время и ресурсы пользователя.
То, для чего давно сделан и отлажен ImageMagick, они делают жаваскриптом!
Но и этого им мало - они, [skipped], еще вынуждают посетителя выкачать ВСЮ pdf-ку с сервера только для того, чтобы показать ему, [skipped], превьюшку первой странички!!!
Вячеслав Правильный, так вы что защищаете-то? Запрос к вашему API (считать только тому, кто подтвердил, что это он) или валидность того, что оно отдает (заносить только то, что было рассчитано для этого сервера)?
FanatPHP, судя по бардаку в вопросе - и то, и другое %)
А если я прав насчет схемы работы, то еще и третье: сервер-сервер в обратную сторону (записи внешних пользователей - во внутреннюю систему).
FanatPHP, я так понял, это что-то вроде системы, в которой у каждой поликлиники свой сервер, но они на один общедоступный сайт валят расписание и запись к врачам. Прямо через открытый у оператора браузер. А на общедоступном сервере - голое API без всяких учеток (почему-то).
Тут в рамках защиты от подделки запроса разве что токен с клиента и обратный запрос к сервера к клиенту на подтверждение, что это он вошел с таким токеном.
Dima07-100, ваша таблица его определяет. У вас должен быть уникальный индекс на поле ID, чтобы при вставке возникла проблема - нельзя вставить такую запись, потому что запись с таким ID уже есть в таблице.
ON DUPLICATE KEY UPDATE разруливает как раз такую ситуацию, обновляя указанные вами столбцы этой записи.
Томас Джефферсон, на бэкенде (mPDF, например) это делается без проблем - там можно назначить PDF как фон для PDF.
На фронте не пробовал, ковыряйте сами какой-нибудь https://pdf-lib.js.org/
Главная проблема - мотивировать пользователей общаться именно у вас на сайте. Будет у вас через полгода семь с половиной сообщений, и нынешний оверинжиниринг станет анекдотом.
Если у вас на сервере достаточно места, вы не будете делать откровенно идиотских запросов к этой таблице и проставите индексы, где надо - никаких проблем с тем, чтобы в базе был десяток миллионов записей, нет.
И предусматривать сложные решения до того, как их наберется хотя бы десяток тысяч, не стоит.
За шит-код извинить можно, а вот за то, что он приведен целиком, а не только те строки, в которых испытываются проблемы - незачет. Уж потрудись вычленить проблему, чтоб ее кто-то стал помогать тебе решать.
Впрочем, добрый человек Wataru уже сказал все, что требуется для решения того, что упомянуто в вопросе. Разбирайся.
Это же явно строчка из синглтона. При первом запросе инициализируется и сохраняется, потом возвращается сохраненное.
Правда, именно то, что вы этого не поняли, говорит против такого кода больше, чем любые стандарты и теории...
Тут-то рабочий график, именно индивидуальные даты. Вплоть до "явился на смену пьяным, ставим прогул" и "вышел на пару дней из отпуска по производственной необходимости". Такие данные отрывать от работника бессмысленно.