Akina

Представим, что проблему сохранения вы как-то решили... А что вы намерены делать с сохранённым значением?

Вариант 1 - всегда только извлекать весь массив целиком, в том виде, в каком он сохранялся. Никаких извлечений части массива, никаких по нему поисков, сортировок и прочего. Тогда преобразуйте массив во вменяемый сериализованный формат и сохраняйте в поле БД. Виктор Кожухарь в своём ответе разобрал этот вариант.

Вариант 2 - возможна какая-то обработка. Извлечение части массива по какому-то критерию (порядковый номер, соответствие шаблону и пр.), поиск в массиве по заданному критерию, сортировка самого массива либо массивов по какому-то критерию.. Тогда однозначно делите массив на отдельные элементы и сохраняйте их по одному (конечно, соответствующим образом должна измениться структура БД). Делить можно и на стороне PHP (как показывает Евгений в своём ответе), и в запросе на запись на стороне MySQL. Первое, как я понимаю, вам проще сделать, но правильно - второй вариант.

Ну типа так:

SELECT DISTINCT
       MAX(player_count) OVER () AS players_max, 
       FIRST_VALUE(`timestamp`) OVER (ORDER BY player_count DESC) AS players_max_timestamp
FROM steam_stats 
WHERE `timestamp` >= '2024-07-01' AND `timestamp` < '2024-08-01'

Если максимальное значение player_count встречается более чем один раз, то будет выведен случайный timestamp из возможных. Если нужен определённый (например, самый последний из них), расширьте выражение сортировки в определении окна.

Или же есть какие-то регламенты или негласные правила при создании вланов на сети?

Есть неписанные правила, которые никто не обязан соблюдать. У каждого они свои. Вот, скажем. мой наборчик:

0. Структура VLAN должна формироваться до создания сети. Любые изменения на уже существующей архитектуре будут достаточно проблемны и болезненны, особенно если сеть 24*7.

1. Default VLAN (он же VLANID = 1) не должен использоваться в сети. Мягкий вариант - в данном VLAN нет ни одного порта, жёсткий - все порты Forbidden.

Исключения:
а) в сети вообще не используются VLAN;
б) имеется оборудование, которое (вопреки документации) не работает правильно без включения транковых портов в default VLAN - например, DES-3028P.

2. Сходные по назначению VLAN образуют группы, в которых VLANID помогает идентифицировать назначение VLAN.

Пример 1: группы с VLANID = 2-99 и 4001-4095 используются как администрирующие (доступ к интерфейсу управления и мониторинга коммутаторов), управляющие (скажем, для MSTP, MPLS и прочих протоколов, требующих отдельного управляющего VLAN) или для какого-нибудь вендор-специфического межкоммутаторного обмена.
Пример 2: группа с VLANID (например) 2x01-2x48 используется в гостинице для обеспечения проводного интернета (клиентского, SmartTV, IP-телефония), соответственно вторая цифра указывает на этаж, а 3-4 цифры на номер комнаты.

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

По-моему, достаточно вычисляемого столбца:

"Итог" numeric GENERATED ALWAYS AS ( COALESCE("Январь", 0) + 
                                     COALESCE("Февраль", 0) + 
                                     COALESCE("Март", 0) + 
                                     COALESCE("Апрель", 0) + 
                                     COALESCE("Май", 0) + 
                                     COALESCE("Июнь", 0) + 
                                     COALESCE("Июль", 0) + 
                                     COALESCE("Август", 0) + 
                                     COALESCE("Сентябрь", 0) + 
                                     COALESCE("Октябрь", 0) + 
                                     COALESCE("Ноябрь", 0) + 
                                     COALESCE("Декабрь", 0) ) STORED

fiddle

И запросов вообще никаких не нужно.

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

Вложенные списки организуют классическую связь 1:N (одному блоку данных соответствует несколько записей из списка).
Если эти строки списка как-то обрабатываются (поиск, фильтрация и пр.), то наиболее разумна схема с 2 таблицами и внешним ключом.
Если же списки только сохраняются и извлекаются, без вообще какой-либо обработки, то можно использовать предложенную mxelgin схему с хранением всего списка в одном поле TEXT либо JSON в сериализованном виде.

SELECT amount || ' ' ||
       CASE WHEN amount % 100 / 10 = 1 THEN 'автомобилей'
            WHEN amount % 10 = 1 THEN 'автомобиль'
            WHEN amount % 10 IN (2,3,4) THEN 'автомобиля'
            ELSE 'автомобилей'
            END
FROM generate_series(0,600) AS source (amount)

fiddle

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

https://www.vmware.com/go/viewclients (перенаправляет на https://customerconnect.omnissa.com/downloads/info..., который недоступен из России, используйте VPN).

Можно использовать не нативный, а браузерный клиент. Там контроль за доступом к локальным ресурсам можно вести ещё и средствами браузера.