Akina

802.1Q VLAN
Базовый, объемлющий, протокол.
К пакету при отправке добавляется информация (дополнительный заголовок) с номером VLAN. Такой пакет называется/является маркированным номером VLAN (тегованным). Соответственно при приёме номер VLAN сверяется с разрешённым, при несовпадении пакет отбрасывается. Мест добавления/контроля, как и способов, существует несколько.

Port-Based VLAN
Разновидность протокола, при котором номер VLAN жёстко связан с физическим портом устройства. Входящий нетегованный пакет маркируется именно тем номером, который зарегистрирован на порте, входящий/исходящий тегованный пакет проверяется на то, что номер соответствует зарегистрированному на порте, иначе пакет отбрасывается. К порту может быть привязано несколько номеров как разрешённые входящие/исходящие для тегованного трафика, но строго один для нетегованного трафика. Исключение - вторым может быть Voice VLAN, но эту ситуацию обслуживает отдельный протокол-надстройка (к тому же он всегда MAC-based).

802.1Q Management VLAN
Номер VLAN, к которому привязан IP-адрес внутреннего интерфейса управления. Из другого VLAN интерфейс по этому адресу недоступен. Внутренний интерфейс может иметь несколько адресов из разных непересекающихся подсетей, тогда каждый будет привязан к своему Management VLAN.

Чисто технически, без понимания сути происходящего:

WITH cte AS (
    SELECT PIP.purchase_id, SUM(PIP.product_count * PR.new_price) AS all_sum
    FROM product_in_purchase AS PIP
    RIGHT OUTER JOIN price_register AS PR ON PIP.product_id = PR.product_id
    GROUP BY PIP.purchase_id
)
( SELECT * FROM cte ORDER BY all_sum ASC LIMIT 1 )
UNION 
( SELECT * FROM cte ORDER BY all_sum DESC LIMIT 1 )

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

Согласно описанию формата, порядок элементов внутри объекта не существует (вернее, не определён), и его поддержание не гарантируется. В отличие от массива.
Так что если порядок важен, то каждая запись должна быть преобразована в отдельный объект, а все они - сложены в массив в нужном порядке, т.е. JSON должен выглядеть, например, так:
'[{"a":1}, {"b":2}, {"c":3}]'

Я его превращаю в json (json_encode), и кладу в бд.

Покажите точно, как выглядит этот JSON.
Покажите точный CREATE TABLE таблицы, в которую кладёте.
Покажите, как точно выглядит в таблице положенное туда JSON значение.
Покажите точно это же JSON значение после обратного извлечения.

Да, всё это - для одного и того же JSON.

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

Более осмысленного ответа на заданный вопрос дать невозможно.

Ни общность кабельной сети, ни территориальность при этом не имеют абсолютно никакого значения.

Причина очень проста. Формально comma-style join - это алиас CROSS JOIN. Но есть подвох - приоритет comma-style join ниже приоритета explicit join. И выражение источника данных, если расставить скобки в соответствии с приоритетом, получится такое:

from
table1 , ( table2
           left join table1 h on table1.id = h.id
           left join table2 s on table2.id = s.id )

Вот теперь прекрасно видно, что внутри скобки о существовании где-то там снаружи table1 ничего не известно.

Правильно - забыть НАВСЕГДА о возможности использовать запятую. И писать вот так:

FROM table1 
CROSS JOIN table2
LEFT JOIN table1 h ON table1.id = h.id
LEFT JOIN table2 s ON table2.id = s.id

PS. Если всё же без comma-style жизнь не мила, можно поступить так, как обычно делают для явного задания приоритета. То есть добавить задающие приоритет скобки:

FROM (table1 , table2)
LEFT JOIN table1 h ON table1.id = h.id
LEFT JOIN table2 s ON table2.id = s.id

Теперь всё в порядке - сначала выполнится запятая, а потом к результату будут LEFT JOIN остальные две таблицы.

CREATE DEFINER=root@localhost
TRIGGER bi_trigger_in_employees
BEFORE INSERT ON employees 
FOR EACH ROW 
SET NEW.entpr_name = COALESCE( NEW.entpr_name, 
                               ( SELECT ap_name 
                                 FROM companies 
                                 WHERE id = NEW.entpr_id 
                                 LIMIT 1
                                )
                              ),
    NEW.employee_name = COALESCE( NEW.employee_name, 
                                  ( SELECT CONCAT_WS(' ',np_surname,np_name,np_patronymic) 
                                    FROM people 
                                    WHERE id = NEW.employee_id
                                    LIMIT 1
                                   )
                                 );

1) Суть ошибки - именно та, что написана в сообщении. Нельзя UPDATE таблицы, на которой определён триггер (и другие DML - тоже нельзя).
2) Изменять вставляемые значения надо до вставки, а не после. Потому BEFORE триггер.
3) По-хорошему, нужен ещё аналогичный BEFORE UPDATE триггер.
4) Все SET выполняются в одном операторе (см. https://dev.mysql.com/doc/refman/8.0/en/set-variab...). А триггер из одного оператора обходится и без BEGIN-END, и без DELIMITER.
5) При скалярном присвоении из подзапроса ВСЕГДА добавляйте LIMIT 1. А по-хорошему ещё и ORDER BY. На показанный код ни то, ни другое не влияет - всё равно одна запись, ибо отбор по PK. Но вдруг структура поменяется, а про триггер забудете? Начнутся ошибки - оно надо?

тогда да, ошибка на бесконечный цикл. Но тут почему?

Как это ни странно, но в теле триггера неизвестно, на какое событие определён триггер.

Что-то типа такого:
FOR %%x IN ("x:\folder\*.url") do browser.exe %%x

CREATE TABLE client ( clientid INT AUTO_INCREMENT PRIMARY KEY,
                      firstname VARCHAR(255),
                      lastname VARCHAR(255),
                      phone BIGINT,                           -- если исходный VARCHAR - поменять, 
                                                              -- либо соотв. преобразование в INSERT
                      UNIQUE (firstname, lastname, phone) );  -- можно потом удалить

INSERT INTO client (firstname, lastname, phone)
    SELECT DISTINCT firstname, lastname, phone
    FROM orders_old;

CREATE TABLE order ( orderid INT AUTO_INCREMENT PRIMARY KEY,
                     ordernumber INT,
                     clientid INT,
                     FOREIGN KEY (clientid) REFERENCES client (clientid) );

INSERT INTO order (ordernumber, clientid)
    SELECT orders_old.ordernumber, client.clientid
    FROM orders_old
    JOIN client USING (firstname, lastname, phone);

NOT NULL - по вкусу.

Нужно каждое слово оборачивать в %?

Нет. Вернее, этого недостаточно.
Условие WHERE name LIKE '%сок%перс%', конечно, не пропустит указанные нежелательные записи - но и "Персиковый сок" тоже будет отброшен.

Нужно проверять наличие каждого слова отдельно.

SELECT *
FROM table
WHERE name LIKE '%сок%'
  AND name LIKE '%перс%';

SELECT test.id, SUM(jsontable.price) total_price
FROM test
CROSS JOIN JSON_TABLE(test.data,
                      '$.products[*]' COLUMNS (price INT PATH '$.price')) jsontable
GROUP BY test.id

fiddle

SELECT *
FROM tablename
WHERE data < CURRENT_DATE + INTERVAL 5 DAY
-- AND data >= CURRENT_DATE

$db->prepare("SELECT comments.id, ... , users.login
                   , :me AS me 
              FROM `comments` ... ");
    $comments->execute([
    "id_post" => $dataAttr,
    "me" => $_SESSION["user"]["id_user"],
    ]);

или типа того...