Vitsliputsli

А рекурсия где, в питоне? может пора узнать про рекурсию на уровне SQL? Так же иногда "дешевле" разом выбрать все записи, а потом уже на уровне python собрать иерархию. Ну и сразу, есть минимум три распространённых способа хранения "вложенности" adjacency list, materialized path, nested sets изучи их.

Для ответа на этот вопрос нужна всего лишь капелька здравого смысла.
Ну и адекватное восприятие реальности, с чем у большинства населения, увы, как раз большие проблемы.

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

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

Ну и поскольку у меня глаза не могут смотреть на эти хаотичные телодвижения, то вот как этот код может выглядеть на самом деле

файл init.php

<?php
$conn = new PDO('mysql:host='.DB_HOST.';dbname='.DB_NAME.';charset=utf8mb4', DB_USER, DB_PASSWORD);  
$conn -> setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION ); 

set_exception_handler(function ($e)
{
    http_response_code(500);
    error_log($e);
    echo json_encode([
            'code' => 'error',
            'message' => 'Internal server error'
    ]);
});

файл с кодом

<?php
// Подключаемся к базе данных
require 'init.php';

// Получаем данные
$list = get_list($conn);

echo json_encode([
    'code' => 'success',
    'data' => $list
]);

Без всей этой кропотливой возни и самоповторов.
Отсутствие данных ошибкой не является. В JS можно проверить массив data и вывести сообщение, что он пустой. Никакой специальный код для этого передавать не нужно.
А настоящие ошибки надо обрабатывать единообразно, в одном месте. А не писать обработку после каждой строчки, причем каждый раз по-разному.

Делают read-only реплику и бэкапят её обычным способом.

Судя по этой статье можно всегда использовать TEXT вместо CHAR(N) и VARCHAR(N), т.к. производительность особо не страдает.

А если самому пойти в документацию, то можно увидеть следующее:

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

Т.е. в производительности разницы нет - только в стоимости хранения. (в отличие от других СУБД)

В реляционных БД не существует гарантий относительно порядка записей внутри таблицы. Этот порядок
- это особенности технической реализации хранения данных внутри блоков и сегментов. Это - "know how"
и это будет зависеть от типа DBMS (Postgres, MySQL, Oracle) и от типа таблицы (heap, index-organized, clustered e.t.c)

Если говорить грубо, то записи (data-rows) лежат не плотно а вразнобой с пробелами с выравниванием
к блокам. Ну тоесть вообще-вообще не так как в Excel. Удаление data-rows в Postgres насколько я помню
физически не удаляет запись а помечает ее мертвой используя служебные поля. Впоследствии VACUUM
делает работы по уплотнению.

Поэтому порядок ты сам обеспечиваешь, делая запрос с опцией ORDER BY some_date_time.

Как уже было сказано - это называется IPC
Если нужно обмениваться данными, то можно использовать техники:
- Сокеты: TCP/IP можно практически везде, Unix-domain - только в unix системах, но будет быстрее
- Сигналы: можно передавать данные вместе с сигналом, но только int/указатель, т.е. вариантов не много
- stdout/stdin: при создании дочернего процесса получить его stdout/stdin потоки и работать с ними
- Каналы: можно создать канал (анонимный или именованный) и общаться через него
- Внешний сервис для общения: какой нибудь RabbitMQ, но это чересчур
- Общая память (Shared Memory): но может не работать во некоторых ЯП
- Общение через файлы: один процесс пишет в файл и по окончании шлет сигнал другому процессу, который этот файл читает
- Memory Mapped File : тот же вариант, что и с файлами, но быстрее и при больших данных можешь словить OOM и большое потребление памяти
- ZeroMQ - это очередь сообщений, которая работает в user-space

Дополнительно надо помнить, что есть ограничения различных платформ, ОС, ЯП и некоторые варианты там работать не будут

Понятно же, что человек просто использует термины не по назначению. А имеет в виду способ взаимодействия с клиентом.
Словом "mvc" он называет классический способ, при котором сервер отдает клиенту HTML (а не JSON).
А словом "api" - REST сервис, при котором сервер отдает клиенту как раз JSON.

И суть вопроса сводится именно к различию между этими двумя способами:
- когда сервер генерирует HTML на основе полученных из БД данных, и отдает его браузеру
- или когда в браузере выполняется программа на JS, которая запрашивает с сервера только данные, а потом на их основе генерирует HTML

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

При этом с точки зрения бэкенд программиста разницы принципиальной между этими способами нет.
Главное в программе - это её бизнес-логика. И уметь надо в первую очередь писать её.
А в каком формате отдавать данные в браузер - дело десятое. И выбирать между "mvc HTML" и "api REST" нет смысла - уметь надо и то и то.

Ну и, как уже объяснили, MVC - это совсем другое. Архитектура приложения. Причем она используется для любых приложений, независимо от типа отдаваемых данных. M и C в "api" приложениях используются в полный рост. Только V немного упрощается. при этом поскольку MVC подразумевается по умолчанию, то и писать её в вакансиях тоже особого смысла нет.

$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 нету. Осталось задать вопрос. Кто вообще дает такую информацию? Что за курсы? Что
за книга? Что за преподаватель?