Akina

1) как сделать так, чтобы через "Сеть 2", "рабочая" (Wi-Fi) шёл трафик ТОЛЬКО на определённые сайты/адреса (в принципе, список IP-адресов почти весь есть), и 2) весь остальной трафик шёл ТОЛЬКО через "Сеть 1" (ethernet), и, соответственно, никак не попадал в "Сеть 2"?

Оставляем Default gateway только через тот роутер, который "Сеть 1" (ethernet). На втором сетевом соединении шлюза по умолчанию быть не должно.
Прописываем частные маршруты на "ТОЛЬКО определённые сайты" через роутер в "Сеть 2", "рабочая" (Wi-Fi). Если к этим сайтам выполняется обращение по именам - все имена занести в файл HOSTS.

Всё собственно.

как оградить "Сеть 2" от попадания в неё трафика из "Сети 1"?

Убедиться, что служба "Маршрутизация и удалённый доступ" - остановлена.

не совсем разобрался с метриками в Windows (установлена Win10) - какие параметры нужно задавать для каждой из этих 2 сетей?

Забудь, это не твой случай.

Отслеживать - нет.
Можно написать скрипт, который будет получать текущую таблицу (interface bridge host print либо interface ethernet switch host print) и сравнивать с предыдущей версией. По результатам сравнения сообщать. Период запуска, само собой, меньше времени жизни записи в кэше.
Хотя разумнее одним скриптом сливать в файл, а потом другим скриптом обрабатывать и кляузничать - но уже не так часто. Или вообще в БД писать, для истории...

1. Собственный сервер - скорее да, чем нет. На Windows - 33/67 (альтернативы - Linux и NAS). AD - точно нет.
2. Коммутатор, разделяющий сеть на изолированные сегменты с помощью VLAN. При необходимости ограниченного или контролируемого доступа из сегмента в сегмент - маршрутизация Микротиком.
3. См. п. 1.
4. Видео - есть. Полезных - нет.

Дополнительно. Организация надёжного резервного копирования, и в первую очередь баз 1С, на независимый носитель - критично обязательно.

SNR-SFP-W35-3 1000BASE-X 3km, 6dB TX 1310nm/RX 1550nm - это одномодовый свисток. Одноглазый, кстати.
ML-SG-2DFM-31LD 1.25G SFP 1310nm 2KM DDM - это многомодовый свисток. Вообще двуглазый.

Они говорят на разных языках. Работают на разном волокне. И никогда друг друга не поймут.

Mission impossible.

Когда каскадное обновление это плохо?

Каскадное обновление - в большинстве случаев это... глупо.

Вспомним, что это вообще такое.

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

По смыслу в основной таблице это поле - как минимум уникально. То есть с точностью до NULL оно является идентифицирующим - то есть если в этом поле не NULL, то определённое значение однозначно идентифицирует строго одну запись. В большинстве случаев же поле в основной таблице, на которое установлена ссылка в подчинённой таблице, вообще является первичным ключом, соответственно не может быть NULL и является истинно идентифицирующим.

Что же есть каскадное обновление? Это изменение связанного значения в подчинённой таблице, если изменяется значение основной таблицы. Ну то есть если изменяется (вспоминаем сказанное выше) значение первичного ключа или поля, объявленного уникальным. В основной таблице. Ага...

Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

Практически всё то же относится и к корректировке просто уникального поля. За исключением случая, когда выполняется каскадное изменение значения поля, которое в основной таблице получило значение NULL. То есть когда выполняемая операция по смыслу является не обновлением, а "мягким удалением" основной записи с каскадным удалением всех подчинённых. Правда, на вопрос, как отличить мягко каскадно-удалённые подчинённые записи от мягко явно-удалённых, и как определить, с какой основной записью была связана мягко удалённая подчинённая, не залезая в журнал или бэкап, ответа никто не даст. А получается, что даже в случае исключения всё делается через "универсальный интерфейс", то есть косяк в проектировании структуры имеется и в этом случае.

Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.

Шаблон:

UPDATE main_table
JOIN ( SELECT id, MAX(created_at) AS created_at
       FROM ( SELECT id, created_at from slave1
              UNION ALL
              SELECT id, created_at from slave2
              UNION ALL
              ...
              UNION ALL
              SELECT id, created_at from slaveN             
              ) AS alldates
       GROUP BY id
       ) AS maxdate USING (id)
SET main_table.created_at = maxdate.created_at

Между маршрутизаторами внутри частной сети WAN или LAN?

Частная - это по-ихнему private.
Private network - это подсеть, которая не маршрутизируется в Интернете (явно или условно). В первую очередь подсети "серых" адресов (RFC 1918), но вообще таких подсетей (именуемых bogon networks) под полтора десятка.
Сеть, адресация которой построена на не маршрутизируемых глобально адресах - это LAN.

Суёшь линк/ярлык в
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

А к какой заднице тут вообще CRON прислонился?

Если же имеется в виду, что указанным запросом надо удалять записи регулярно - то CRON для решения такой задачи просто нафиг не нужен..

Using the Event Scheduler

PS. И в запросе следует избавиться от WHERE IN и переписать его на обычный JOIN.

Ну там не головоломки, а самые обычные задачки.

Да, сайты, где есть не только SQL-задачи, но и их решения, имеются. Тот же sql-ex, например.. Правда, не припомню таких, где бы предлагалось и объяснялось решение именно авторами сайта - решения (а практически любая задача имеет много альтернативных, порой радикально различающихся подходом, решений) можно найти либо в комментариях пользователей к задаче, либо на прилагаемом форуме.

Простейший запрос к гуглю, ну типа задачи OR упражнения по sql даст кучу ссылок - что приятно, большинство русскоязычные. Выбирай не хочу.

И ещё момент. Большинство задач там синтетические, и бывают задачки на довольно странной структуре таблиц, противоречащей всем и всяким правилам и требованиям нормализации. Помните об этом, и не учитесь плохому...

Если вес является единственным параметром, то это "Задача линейного раскроя".

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

Оборудование на другом конце - ситуация штатная. Тестер обязан её предусматривать, в т.ч. и вариант с PoE.

Про убитый тестером порт даже не слышал. Но если такое произойдёт, то это будет явно следствие неисправности тестера. Либо "после, но не вследствие".

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

UPDATE test
JOIN ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) new_id
       FROM test ) AS cte USING (id)
SET test.new_id = cte.new_id;

id - UNIQUE NOT NULL, либо вообще PRIMARY KEY. Поле либо выражение.

Предполагая, что тип данных поля - DECIMAL(xx, 3):

SELECT MIN(value) + 0.001
FROM test t1
WHERE NOT EXISTS (
  SELECT NULL
  FROM test t2
  WHERE t1.value = t2.value - 0.001
  );

https://dbfiddle.uk/9Yyi-pol

PS. Возвращаемое значение не может быть меньше минимального из уже имеющихся в таблице.

из той статьи появилось предположение

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

Таблица часто join-тся в запросах через hash.

Что, берутся все записи таблицы, и сортировка выходного набора тоже по этому полю? нет? тогда статья тут близко не лежала.

"hash" - это primary key и содержит md5 текста

Тип данных и размер мы должны сами придумать?

Какое преимущество для текущей конфигурации обеспечивает настройка сетей VLAN?

Это же учебное задание, верно? и, поскольку маска у клиентских узлов не указана, следует полагать, что используется классовая адресация, и соответственно все 6 указанных узлов находятся в одной подсети.

В этом случае деление на VLAN однозначно убирает взаимную "видимость" узлов, включённых в разные VLAN, а также разделяет широковещательный трафик. Опять же безопасность и всё такое...

Можно же взять S1 и подключить к нему PC1, PC4 и т.д.

Это же учебное задание, верно? ну так если имеется именно показанная схема, без обозначенных пространственных зон, то однозначно предполагается, что подключение клиентских узлов к другим коммутаторам - невозможно физически.

Так что никаких "можно же взять" - нельзя, и точка.

WITH cte AS (
  SELECT *,
         SUM((flag IS NULL) :: INT) OVER (PARTITION BY user_id ORDER BY product_id ASC) grp
  FROM test
  )
SELECT product_id, user_id, flag,
       DENSE_RANK() OVER (PARTITION BY user_id ORDER BY grp ASC) "rank"
FROM cte
ORDER BY 1,2;

fiddle