Ипатьев

5 июня вы уже задавали этот вопрос.
Если за три месяца вы так и не освоили базовые приёмы работы с БД в РНР, то может ну его совсем?
Тем более что при таких-то дырищах всё равно это будет не баланс, а решето.

А зачем if-ы вкладывать друг в друга?
Как $tegi[1] может быть одновременно равен $id['TIP_TOVARA'] и $id['AFFILIATION']?

Если отвечать на вопрос, который в заголовке, и который не имеет никакого отношения к озвученной задаче: сначала надо определиться, как отличать объекты друг от друга.

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

$send .= "sudo screen -dmS screen_name docker run $user_container $memory_container -d -it --cpus '1' --memory=" . $mem."m $v1 $v2 $v3 $v4 $v5 -e LANG=C.UTF-8 -e LC_ALL=C.UTF-8 $v6 $v7 $v8 $v9 $v10 $v11 $v12 $v13;";

но как же я задолбался все эти кавычечки выковыривать

Весь вопрос в требуемой точности.
Я могу написать в юзер-агенте что у меня FireChrome Opera версии 100500 для межгалактических планшетов.
А на самом деле это будет Brave для PC XT.

Однако для любых осмысленных применений точности определение вполне достаточно. Существует 100500 либ, которые выдают все требуемые характеристики по юзер-агенту.
Собственно, все сайты в интернете так и работают, в частности определяя мобильность клиента.

Технически равноценны, но второй при сравнении с нулём выглядит глупо.
Хорошо или не хорошо - вопрос философский. РНР до сих пор язык со слабой типизацией, и никаких подвохов или расходов тут нет.
Я бы сказал, что неявное приведение к булеву типу до сих пор используется повсеместно, что в if, что в while. Особенно в последнем. Писать while (($row = $stmt->fetch()) !=== false) вместо while ($row = $stmt->fetch()) пока ещё народ отказывается.

Понятное дело что ни к посетителям, ни к сессиям мемкеш никакого отношения не имеет, как и РНР. HTTP - это stateless протокол, и все клиенты в РНР на одно лицо.
Мемкеш - это демон, который обслуживает входящие соединения, которые для него тоже все на одно лицо. Причём это лицо - РНР, а не какой-то там НТТР клиент.
РНР конечно может создать ключ в мемкеше на основе куки, полученной от пользователя, но для мемкеша это будет совершенно обычный ключ, не привязанный ни к какому "клиенту". А всё привязка - это чисто интерпретации на уровне пользовательского РНР кода.

А вот почему тормоза и дубли - тут я ответить не могу, потому что с мемкешем сталкивался лет 10 назад по касательной. Это к вопросу о том, что искать часы надо там, где потерял, а не не под фонарём потому что светлее. И задавать вопрос надо про исходную проблему, а не про свои догадки по её поводу.

По идее никаких дублей в мемкеше быть не должно - это key-value хранилище и ключи должны быть уникальными.
Возможно, выгрузка показывает уже просраченные ключи.
А тормоза, возможно, из-за того, что ключи постоянно перезаписываются, вместо того, чтобы записываться только тогда, когда надо обновить данные.

В целом мемкеш уже давно вышел из употребления, и его заменил редис

Почему не нужно заранее объявлять массив?

Как правильно заметили в комментарии выше, "это РНР, тут так можно".
Раньше вообще можно было инициализировать переменную как строку, и потом обращаться к ней, как к массиву.
Начиная с 7 версии начался отход от таких вольностей, но он всё ещё в процессе.

Значит то что пишут $result = [] Это я удобства?

Не для "удобства", а для того, чтобы волосы на голове сохранились подольше.
В данном случае нужды в явном присвоении нет.
Но любой код со временем изменяется. И функция tower_builder() может разрастись. Там появится ещё один цикл, который работает с массивом $result. Который получит какое-то значение до начала нашего цикла, и в итоге конечный результат будет неправильным. Поэтому $result = [] перед началом работы с массивом - это не каприз или удобство, а необходимость

Потому что ./css/style.min.css - это бессмыслица и карго культ.
Ссылки на локальные ресурсы должны быть абсолютными путями от корня сайта. А не вот это вот.
То есть в данном случае надо убрать точечку.

Ну ведь всё просто же.
В отличие от файловой системы, где никогда заранее не знаешь, где у неё корень, с веб сайтом всё просто и понятно, корень всегда один - /
/ - корень сайта
/css - папочка css в корне сайта
/css/style.min.css - файл style.min.css в папочке css которая лежит в корне сайта
Всё просто, понятно, очевидно

Зачем вообще было писать эти точечки?
Они начинаются, когда ты только учишься склыдывать а и б в HTML. И нет у тебя никакого веб-сервера, а есть файлик на диске. В этом случае да - без относительных путей никак не обойтись
Но как только начинается РНР, который без веб сервера уже не работает, про все точечки в локальных ресурсах надо забыть, и писать всегда абсолютные пути от корня сайта.

Во-первых, зачем тут первый запрос?
Во-вторых, кроме количества совпадений надо наверное запрашивать и сам id? Ну по логике? если мы хотим вывести id, то надо наверное это поле указать в SELECT?
В-третьих, надо добавить группировку, GROUP BY
В-четвёртых, если надо вывести любые значения из первой, а не только те, у которых есть записи во второй, то нужен LEFT JOIN