Akina

WITH cte AS ( SELECT name, last_name, cnt FROM table
              UNION ALL
              SELECT name, last_name, cnt - 1 FROM cte WHERE cnt > 1 )
SELECT name, last_name FROM cte;

aopil,

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

SELECT *
FROM services
JOIN (
    SELECT *,
           @row_number := CASE WHEN service_id = @service_id
                               THEN @row_number + 1
                               ELSE 1
                               END rownumber,
           @service_id := service_id
    FROM orders
    CROSS JOIN (SELECT @service_id := 0, @row_number := 0) init_vars
    ORDER BY service_id, id DESC
    ) enumerated_orders USING (service_id)
WHERE enumerated_orders.rownumber <= services.service_limit

https://dbfiddle.uk/?rdbms=mysql_5.7&fiddle=1f2a95...

Информация о том, что пользователь оплатил подписку заносится в бд (есть отдельная строка, в которой изначальное значение равно нулю, а при оплате меняется на 1).

В комплекте с информацией о факте оплаты должна существовать и информация о дате-времени открытия доступа по подписке. Кстати, в этом случае сама информация о факте оплаты не нужна, достаточно просто самого факта наличия момента оплаты либо срока действия оплаченного доступа.

значение сменилось на 1, а потом через месяц само сменилось на 0.

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

MySQL 8.0 Reference Manual / Stored Objects / Usin...

хотелось бы посмотреть на версию mysql 5.7

Ну например так:

SELECT department.name as department_name, 
       employee.name
FROM employee 
JOIN department ON employee.department_id = department.id 
WHERE 2 > ( SELECT COUNT(*)
            FROM employee emp
            WHERE emp.department_id = employee.department_id
              AND emp.id < employee.id )

Ну или так:

SELECT department.name as department_name, 
       subquery.name
FROM department
JOIN ( SELECT employee.*,
              @row_number := CASE WHEN @department = department_id
                                  THEN @row_number + 1
                                  ELSE 1
                                  END rownumber,
              @department := department_id
       FROM employee
       CROSS JOIN ( SELECT @department:=0, @row_number:=0 ) variables
       ORDER BY department_id, id ) subquery ON subquery.department_id = department.id
WHERE subquery.rownumber <= 2

fiddle

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

Обломись.

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

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

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. Но вдруг структура поменяется, а про триггер забудете? Начнутся ошибки - оно надо?

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

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