Можно повесить статичную плашечку на файл "Сей файл подписан и утвержден Ивановым Иван Иванычем 01.03.2023 12:04:45 находясь в добром здравии и уме". Важно, чтобы никто кроме авторизованных пользователей, кто отвечает за эту плашечку не мог ничего менять без согласования Иванова И.И.
Простая электронная подпись неотделима от системы, которая контролирует ее учет. Подписи можно доверять, если есть доверие к системе, которая сообщает ее статус.
Чисто на интуиции, я не доверяю современным системам охлаждения ноутов. Охлаждение четко выверено инженерами под определенный уровень тепловыделения. Если со временем, что-то ухудшается в сборке этой системы, то можно увидеть чудеса перегрева. Поэтому, как собрана система охлаждения - это попадает первым под подозрение, если проявляется такое. Хотя если ноут боязно вскрывать любыми путями, ввиду потери гарантии, то стоит поискать другие версии происходящего.
Руководитель и Исполнитель - это, по хорошему просто Человек.
А руководитель и исполнитель - это Роли (отдельная таблица). Осталось понять, если роль дается на задачу, то внешний ключ Роли идет на задачу, если Роль постоянна и не меняется от задачи к задаче - то на человека внешний ключ роли нужен.
Для вашей схемы достаточно указать в Расписании внешний ключ исполнителя, так как у вас что-то не так с сущностями Исполнители - они у вас "одноразовые" подучаются. Вам под каждую новую задачу придется вписывать нового исполнителя. Между Задачами и Исполнителями напрашивается отдельная сущность "Исполнитель задачи", в которой будут внешний ключ к Задаче и внешний ключ к Исполнителю - тем самым с помощью этой промежуточной таблицы реализуется связь "многим-ко-многим".
Если расписание нужно для фиксации периодов работы над задачей без детализации по исполнителям, то в записи расписания нужен только внешний ключ задачи. А исполнители подтянуться из сущности Исполнитель задачи.
Если выполнение каждой задачи нужно детализировать по разному набору исполнителей одной задачи, то вам нужно разбить сущность Расписание на две - "Расписание", и "Исполнитель задачи по расписанию"
Записи Расписание будет содержать внешний ключ на задачу, а запись "Исполнитель задачи по расписанию" внешний ключ к Расписанию и внешний ключ к Исполнителю задач (или к Исполнителю - не принципиально).
Пока не приведете свойства каждой сущности, то не понятно, какими связями должна обрасти сущность Расписание.
При анализе предметной области можно не доглядеть, допустим в сущности Задача - сущности Подзадача, у каждой из них могут быть отдельные исполнители. И не понятно, что хотите получить в расписании - фиксацию работы одного исполнителя, период времени работы над задачей?
Навыки корректного парсинга любых источников данных.
Идеально, если у вас есть в портфолио проект "серого" магазина-агрегатора, который корректно слизывает список товаров из официальных магазинов (естественно, не по их API, а по содержимому страниц. Естественно, без их ведома. Естественно, превозмогая изменяющуюся верстку страниц и структуру наполнения).
Сложно ли?
Делать не сложно. Сложно будет правильно формулировать вопросы заказчику по каждой мелкой детали в структуре входных документов. Особенно, по части:
- деталь структуры документа формируется полностью автоматически?
- зафиксирован ли стандарт формирования этой структуры?
- может ли человек вмешаться в структуру документа, без автоматических средств формирования такого документа - какие варианты бывают, какие корректные, какие ошибочные. Как детектить разного рода вмешательства?
И подобного рода вопросы вы должны уметь задавать и находить по ним решение, чтобы начать просто доставать корректные данные.
Если решите эту проблему, то вторую часть задачи - сформировать выходной документ будет уже проще.
Вы уверены, что хотите 1080 на 27+ диагонали?
Будете видеть сетку пикселей как во времена MS-DOS.
1080 комфортно смотрятся до 24 дюймов, дальше нужно увеличивать разрешение минимум до 2К.
Любо большой моник придется использовать только как телевизор или кинотеатр, для других целей 1080 в такой большой диагонали не целесообразен.
А где описание ваших попыток найти ошибку по логам PHP или по тому, что выдает функция mysqli_error()?
Если вы только пишете код (10% времени) и не проводите детективное расследование, как Шерлок Холс (90% времени), тратя время на эксперименты и поиск ошибок, то программистом никогда не станете.
На Q&A надо приходить с версиями таких изысканий.
Отключаете шлейф питания диска. Подгружаетесь с системы или с загрузочной флешки, где есть Виктория или подобная утилита, пока не запускаете ее. Вставляете шлейф питания (аккуратно, не перепутать полярность), и после инициализации диска (и определения его в системе, если запускали ОС) запустите утилиту. Пока диск активном состоянии снимите показания Смарта и попытайтесь запустить проверку диска.
Планки с пониженным напряжением (L) могут работать в слотах, где не предусмотрено понижение напряжения.
Вопрос лишь в том, расшарит ли установленный процессор все 16 Гбайт.
Какая модель процессора?
1. <form action="gg.php"> if(isset($_POST['search'])){
В теге не указан метод передачи. Этот метод по умолчанию точно не POST, еще GET бывает - нужно явно приписать метод. Поэтому, в $_POST ловить нечего.
2.
Сразу несколько вопросов по синтаксису SQL и способом взаимодействия с СУБД.
2.1 Откуда вы взяли, что в SQL дизъюнкция это || а не OR?
2.2 %...% - вы точно проценты видели в документации к SQL применительно к равенству, а не к like-у?
2.3 search - вы уверены, что переменная из PHP подставиться в запрос без $ ? Даже не беря во внимание, что склеивать строки запроса - это дурной подход. Правильнее использовать подготовленные запросы.
1. Пробовали распаковать отдельный условно-целый файл, который находится за поврежденным томом?
2. Сколько не хватает данных в каждом томе (в %)? У томов начало файла гарантировано имеется?
3. В архив добавлены избыточные данные для восстановления (сколько процентов)? (если по 2-ому пункту очень маленький процент и есть начало файла, то восстановление может помочь).
Все запросы, которые имеют входные или выходные параметры, нужно подготовить, выполнить и если надо произвести выборку результата.
В методах Вордпресса get_results, get_row, get_col совмещено два действия - выполнение (execute) и выборка результата (fetch). Отдельного метода execute для случаев, где просто нужно выполнить в документации не просматривается.
Я понимаю, что любым их этих методов можно пнуть подготовленное выражение и оно выполнится.
Простая электронная подпись неотделима от системы, которая контролирует ее учет. Подписи можно доверять, если есть доверие к системе, которая сообщает ее статус.