Vitsliputsli

$arr = explode(',', $str);
foreach ($arr as $value) {
    $new_arr[] = trim($value);
}

Зачем использовать регулярки, если они не нужны в задаче.
А если нужны по заданию, то

Мусорные процессоры - Пикабу

У вас код написан с синтаксисом PHP 8, а запускаете вы код на более старой версии PHP, которая не понимает этот синтаксис. Конкретно речь идёт об именованных аргументах. Обновите PHP или пишите без имен аргументов.

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

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

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

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

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

В первоначальном варианте ООП Аллана Кея было событие. Грубо говоря Кей считал объекты акторами.
И от этого рисовал своё видение разработок. Но его кунг-фу не полетело в свое время. Слишком рано
было.

В современном классическом ООП в его реализации С++ и Страуструпа
нет никаких событий. Нету ключевых слов. И нету среды которая-бы обеспечивала путешествие
этих события вне объектов.

Событие может появляться например как абстракция прикладного уровня в библиотеках типа MFC
которы должны были работать с UI и регистрировать мышко-клики и прочее. Но там была ОС которая
обеспечивала буфер событий. Отдельный life cycle для каждого из них. Вот. А языс Microsoft Visual C++ / MFC
предоставляли как-бы фреймворк который регистрировал хендлеры и там соотв. эти события ловил и обрабатывал. Но это было сами понимаете никакое ни ООП. А это была очередная абстракция от Microsoft
которая по их задумке должна была упрощать процесс разработки графического софта.

В Borland C++ тоже есть свои абстракции для событий. Но они тоже лежат как-бы отдельно от языка. Скорее
во фреймворке или в библиотеках.

Откуда в PHP-OOP вдруг появляется событие? В ключевых словах PHP есть class, trait, function, abstract, extends.

Но никаких event нету. Осталось задать вопрос. Кто вообще дает такую информацию? Что за курсы? Что
за книга? Что за преподаватель?

у вашего юзера небось логин шел по умолчанию был не баш
как узанть

grep $(whoami) /etc/passwd | cut -d : -f 7

/bin/bash

как поемнять
usermod --help

там написано как шел заменить

-s, --shell SHELL             new login shell for the user account

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

--UPDATE stats SET NEW.globalnum = NEW.num1 + NEW.num2;
++SET NEW.globalnum = NEW.num1 + NEW.num2;

А лучше рассмотрите вариант генерируемой колонки, тогда не понадобится никаких триггеров.

самое быстрое - чтенгие из файла, csv в MyISAM потом замена на innodb или другой движ
медленнее - убивание индексов из SQL сценария и ручное создание после
ну и самое медленное AS IS

а тае настройки до Ж все, в пределах 50% идеале процентов прирост

Очевидный пример:
Допустим у тебя есть таблица с домашними животными и таблица с хозяевами домашних животных.

Чтобы указать у животного, кто его владелец - ты заводишь колонку "идентификатор владельца".

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

В случае попытки удалить запись о владельце, на которого кто-то ещё ссылается, или при попытке указать несуществующий ИД - СУБД выдаст ошибку, что было нарушено ограничение.

Ветка - это указатель на коммит. Удаляя ветку, вы удаляете указатель, если на этот коммит больше нет указателей, то он "потеряется" (найти его можно будет только через git reflog).

Имеется система логов, которая довольно часто вызывается, при пиковых значениях достигает до 30-40 записей в секунду. Использую engine ARCHIVE, сервер MariaDB, подключение по unix сокету.

Имеет ли смысл собирать кучу данных допустим 50 записей и потом одним запросом добавлять 50 записей.

Смотри. Писание логов в Марию - это как по мне лишнее. Оверинжинеринг. В наше время логи собирают logstash-ем и пишут в Кибану. Там для каждого формата есть свой парсер. Для Ninx, Apache e.t.c.

Если тебе прям сильно-сильно надо писать логи в реляционную систему (очевидно что-то джойнить с логами) - то пиши максимально большой пачкой. Хоть 1000 штук. Сколько позволяет размер фрейма в этом unix socket. (Кстати какой он там?) А чорт его знает. Но.... если ты записал 999 записей а последняя еще не пришла, а тебе срочно нужно глядеть в базу - тогда делай периодически сброс по времени. Например через 3 секунды от начала пачки ты будешь делать insert независимо от того сколько строк накопил.

Вот так.