Akina

SELECT address, 
       office, 
       t1.fio, 
       t2.counter, 
       CASE t2.counter
           WHEN 'counter1' THEN t1.counter1
           WHEN 'counter2' THEN t1.counter2
           WHEN 'counter3' THEN t1.counter3
           END value,
       t2.num,
       t1.date       
FROM table1 t1
JOIN table2 t2 USING (address, office)

Надеюсь, коммутатор управляемый?

Смотрим ARP коммутатора. Некоторые МАС можно идентифицировать сразу - например, у большинства сетевых принтеров МАС написан на шильдике. Хотя, судя по поставленной задаче и имеющемуся бардаку, клиентов немного, так что обойти все компы и переписать МАС-и недолго.

Берём ноут либо планшет с сетевухой (USB). Втыкаемся в розетку или коммутатор. Смотрим в ARP в интерфейсе сиськи, на каком порте находится МАС сетевухи.

А ещё есть генераторы, которые "свистят" в кабель. И к ним щуп, который определяет наличие этого "свиста" в кабеле либо розетке. Но это либо вдвоём, либо много бегать.

Почему не работает функция CURRENT_DATE() в триггере?

Где-то что-то криво делаешь. У меня - работает.

Хотя с моей точки зрения - у тебя кривая таблица. Нафига нужен триггер, если существует такая штука как "значение по умолчанию"?

CREATE TABLE Sotrudnik (
  .....
  Date_Prinyatiya DATE DEFAULT (CURRENT_TIMESTAMP),
  .....
);

FIDDLE

PS. Обращаю внимание - скобки в выражении значения по умолчанию обязательны!

rundll32.exe keymgr.dll, KRShowKeyMgr

Есть другая локальная сеть.

Eсли термин "другая локальная сеть" использован правильно, и речь идёт о физически изолированных сетях - то без объединения сетей - на самом сервере (вставить в него вторую сетевую) либо на отдельном устройстве в первой сети,- задача очевидно не решается.

Как сделать так что бы при вводе другого IP адреса с другой подсети пользователь попадал на сайт 10.2.2.10?

Если вопрос ставить ИМЕННО ТАК - то либо использовать destination NAT в варианте DMZ, либо socks proxy.

Любые остальные решения подходят только в случае, когда будут чётко определены конкретные протоколы и, для TCP/UDP - порты. И когда будет чётко и однозначно определено, что скрывается под загадочным термином "попадать".

вывести эту информацию в файл, с условием того, что файл можно будет загрузить и продолжить редактирование.
...
хочу оставить пользователю возможность просматривать (было бы неплохо и редактировать) файл
...
Скорее всего в документ буду выводить таблицей или списком текущие задачи и статус их выполнения.

Такое однозначно требует plain text.

Во-первых, всё должно быть максимально просто. Соответственно про бинарные, а тем более проприетарные, форматы - забудь.
Во-вторых, уж редактор, а тем более вьювер, для текстовых файлов сейчас можно найти даже в утюге. Лишь бы он после импорта и редактирования текста не стремился сохранить результат в своём хитровыделанном формате.
В третьих, чтобы при редактировании не соблюсти простейший текстовый формат, надо быть полным [censored].

Соответственно первый кандидат на формат - это CSV/TSV. Я за CSV с горизонтальным выравниванием при выводе (но игнорированием его при обратной загрузке), при обязательном требовании обрамления значений символом двойной кавычки. С соблюдением такого формата при редактировании справится и обезьяна.
Второй кандидат - это текстовые форматы сериализации (JSON, XML и т.п.). Но там сложнее соблюдать формат при редактировании.

Есть устоявшаяся практика: присваивать номер vlan номеру подсети

Вот честно - слышал, но никогда не мог понять. Как по мне - хрень голимая. Качественное документирование куда как полезнее.

Более того, никогда не понимал и горячее желание иметь одну подсеть на вилан. Но тут хотя бы понять можно, почему.

понятно ограничение на количество vlan на разном оборудовании

Если оборудование не поддерживает стандарт, который определяет 4к различных VLAN, то разумнее его не использовать - кто знает, что оно ещё делает не по стандарту...

В рамках реляционной СУБД для описанной схемы есть несколько принципиально разных подходов.

Первый - одна таблица и NULL в полях, отсутствующих у конкретного типа, её описывает Сергей Соловьев, вариант 2.
Второй - использование EAV. Удобно, динамично, но проблемы с производительностью. Хотя из всех паттернов для реляционных СУБД он походу наиболее применим для фасетного поиска.
Третий - использование сериализованного формата хранения. Например, хранение свойств объекта в формате JSON. Но, поскольку требуется поиск по атрибутам, в этом случае необходимо будет использовать внешний поисковый движок, возможно, даже ориентированный на фасетный поиск, или будет ужас как медленно.

Использование MongoDB на описанном материале (буквально пара типов объектов) мне кажется не очень соответствующим решением. Хотя зависит от планируемого объёма данных.

Для всех полей, которые не указаны явно в запросе на добавление (то есть поля явно перечислены в предложении INSERT, но это не все поля таблицы, есть неупомянутые в списке поля), в шаблон вставляемой записи помещается указанное в структуре таблицы значение по умолчанию. Если таковое отсутствует, то в шаблон помещается NULL.

Поле-автоинкремент не имеет значения по умолчанию. Генерация нового автоинкрементного значения производится после выполнения всех BEFORE триггеров. Отсюда и NULL в указанной ситуации.

PS. https://xyproblem.info/

Легко решается триггером. Пример:

- исходная таблица:

CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(100),
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

- триггер:

CREATE TRIGGER tr_users_bi
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
  DECLARE allowed_created_at DATETIME;
  DECLARE error_message_text VARCHAR(64);
  SELECT MAX(created_at) + INTERVAL 12 HOUR INTO allowed_created_at
  FROM users
  WHERE username = NEW.username;
  IF NEW.created_at < allowed_created_at THEN
    SET error_message_text = CONCAT('Регистрация возможна не ранее ', allowed_created_at);
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = error_message_text; 
  END IF;
END

DEMO fiddle

PS. Надеюсь, получение сгенерированного сообщения об ошибке и показ его юзеру не составит проблемы..

Как реализовать надежную запись списка данных без пропусков значения автоинкремента id?

Никак НЕ РЕАЛИЗОВЫВАТЬ.

Оставь автоинкремент в покое - он обязан обеспечивать только уникальность, и не более. Нужна непрерывная нумерация? Создай для неё ОТДЕЛЬНОЕ поле, и нумеруй программно. Триггеры в помощь.

Можно ли одним запросом вывести все товары и свойства которые соответствуют данному товару
id товара, название, свойство, значение......все свойства, значения.

1; Ручка; Цвет; Синий; Цена; 10
2; Нож; Материал; Цена; 200; Рукоятка; Дерево; Фото; Есть;

Приведённый хреново форматированный текст не позволяет понять, где какое поле, и какой в нём тип данных.

Полное ощущение, что автору требуется куча колонок (в смысле полей в структуре выходного набора). ТО есть если свойство одно, полей 4, если свойств 2, полей 6, и так далее...

Если так, то требуемый результат называется "сводная таблица" (pivot table). Это совсем даже не реляционная структура, у которой нет и тени шанса попасть в стандарт, а потому практически ни одной СУБД штатно не поддерживается. Из популярных оно есть исключительно в SQL Server, да и там скорее исторически сложилось, чем нужно было.

В MySQL / MariaDB ничего подходящего нет. И если кому оно реально необходимо, приходится возиться руками - хранимая процедура, динамический код... хотя на порядок разумнее оставить данные в EAV, а сводную таблицу строить на клиенте на его сервисе отчётов.

Если же устроит выдача всех свойств, собранных в одно сериализованное поле (например, объект JSON) - то это обычная группировка и агрегация.

в случае совпадения, указать "ничего не делаем"

Реверсируйте условие и ничего не делайте в случае НЕсовпадения, т.е. в ELSE. Которое в этом случае можно вообще не писать.

Насколько крупный должен быть бизнес, чтобы человек был не админом-универсалом, а трушным сетевиком?

В основном это определяется не размером конторы, а областью её деятельности и разветвлённостью её сетевой инфраструктуры.

Мелкой, средней, и даже крупной конторе, но не имеющей разветвлённой сетевой инфраструктуры, выделенный сетевик в общем-то не нужен, как правило, вполне достаточно системного админа (или нескольких) с соответствующими скиллами.

Крупной конторе с разветвлённой сетевой инфраструктурой (как правило, речь о территориально распределённых) выделенный сетевик или даже отдел - нужны. А если проблемы в сетевой инфраструктуре способны сильно влиять на бизнес и приводить к серьёзным потерям - то такой отдел необходим.

Крупной конторе, предоставляющей услуги связи другим конторам (т.е. тем, у которых сетевая инфраструктура - одно из главных средств производства), выделенный отдел сетевиков абсолютно и критично необходим. Причём там должны быть и сетевые администраторы, и сетевые инженеры - это весьма разные должности функционально. Список таких областей деятельности достаточно узкий - связисты, провайдеры, ну ещё датацентры, пожалуй, ну и всё.

является ли такой режим и график работы для сетевика нормой?

Для организации, имеющий соответствующий отдел и службу быстрого реагирования (последняя категория из описанных выше) - совершенно ненормально.

Для организации, у которой службы быстрого реагирования отсутствует - хоть и ненормально, но, увы, типично. И хорошо, если эта особенность соотв. образом учитывается в зарплате, но такое бывает далеко не всегда.

Можно, конечно, использовать какую-нибудь дурь типа

WITH cte ( поля ) AS (
    -- твой запрос
    )
SELECT [ поля ] FROM cte
UNION ALL
SELECT NULL, ... , NULL WHERE NOT EXISTS (
    SELECT NULL FROM cte
    )

Но, право слово...