Для вашей схемы достаточно указать в Расписании внешний ключ исполнителя, так как у вас что-то не так с сущностями Исполнители - они у вас "одноразовые" подучаются. Вам под каждую новую задачу придется вписывать нового исполнителя. Между Задачами и Исполнителями напрашивается отдельная сущность "Исполнитель задачи", в которой будут внешний ключ к Задаче и внешний ключ к Исполнителю - тем самым с помощью этой промежуточной таблицы реализуется связь "многим-ко-многим".
Если расписание нужно для фиксации периодов работы над задачей без детализации по исполнителям, то в записи расписания нужен только внешний ключ задачи. А исполнители подтянуться из сущности Исполнитель задачи.
Если выполнение каждой задачи нужно детализировать по разному набору исполнителей одной задачи, то вам нужно разбить сущность Расписание на две - "Расписание", и "Исполнитель задачи по расписанию"
Записи Расписание будет содержать внешний ключ на задачу, а запись "Исполнитель задачи по расписанию" внешний ключ к Расписанию и внешний ключ к Исполнителю задач (или к Исполнителю - не принципиально).
Пока не приведете свойства каждой сущности, то не понятно, какими связями должна обрасти сущность Расписание.
При анализе предметной области можно не доглядеть, допустим в сущности Задача - сущности Подзадача, у каждой из них могут быть отдельные исполнители. И не понятно, что хотите получить в расписании - фиксацию работы одного исполнителя, период времени работы над задачей?
Навыки корректного парсинга любых источников данных.
Идеально, если у вас есть в портфолио проект "серого" магазина-агрегатора, который корректно слизывает список товаров из официальных магазинов (естественно, не по их 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 для случаев, где просто нужно выполнить в документации не просматривается.
Я понимаю, что любым их этих методов можно пнуть подготовленное выражение и оно выполнится.
Интересно, а как вы получаете состояние на клиенте, что клиенту пришло входящее сообщение?
PHP по своей инициативе такое не отправит: echo '<div id="ввывод">тут уведомление</div>';
Нужно, чтобы браузер первый запросил. Либо у вас должно быть поднято WebSocket соединение.
СМАРТ показывает проблему позиционирования головок (параметр 7), до этого посекторных переносов и ошибок не накапливалось (параметры 5 и 196). Очень может быть, что поверхность диска целая и вам могут помочь в фирмах восстановлению данных.
Сами вы можете только снять плату управления диска, не раскручивая гермоблок (!!!), и почистить контактные площадки на плате ластиком, куда подключается двигатель и головки. Если на контактах большой слой окислов, то это может быть фактором, почему головки не работают.
Раскручивать гермоблок - это смерть для поверхности диска, если это делать вне чистой комнаты.
Если расписание нужно для фиксации периодов работы над задачей без детализации по исполнителям, то в записи расписания нужен только внешний ключ задачи. А исполнители подтянуться из сущности Исполнитель задачи.
Если выполнение каждой задачи нужно детализировать по разному набору исполнителей одной задачи, то вам нужно разбить сущность Расписание на две - "Расписание", и "Исполнитель задачи по расписанию"
Записи Расписание будет содержать внешний ключ на задачу, а запись "Исполнитель задачи по расписанию" внешний ключ к Расписанию и внешний ключ к Исполнителю задач (или к Исполнителю - не принципиально).