FanatPHP

Ошибка Couldn't fetch mysqli означает что ты где-то уже закрыл соединение с БД зачем-то

Ну и чтобы ответить на вопрос из заголовка и переписать весь этот пещерный ужас на нормальный РНР

$b = $conn->query("SELECT * FROM users WHERE name = 'alex'")->fetch_all(MYSQLI_ASSOC);
if($b) {
    print_r($b);
} else {
  echo "0 results";
}

ну вот конкретный пример, как сохранить объект в БД? Таким образом как я сделал?

Если ты создал класс для того чтобы сохранять его объекты в БД - то нет, не нужен.

Вообще, порог вхождения в ООП очень высокий. Особенно в сравнении с порогом вхождения похапе. Из 100 человек, пользующихся РНР, хорошо если один может понять, зачем ему классы. Так что в целом ничего страшного, если ты не понимаешь. Хотя мне кажется, что ты движешься в правильном направлении. Просто не надо думать, что с ООП получится так же легко и само собой, как с процедурщиной. Тут надо мозги нанизнанку выворачивать.

А с классом надо так - сначала думаешь,зачем он тебе, а потом создаешь. Не наоборот :)

Не "сериализовать", а нормализовать

Сделать отдельную таблицу, в которой будет две колонки, id из исходной строки и id книги.

Дальше делаем совершенно тупой запрос

SELECT a.* FROM actions a, actions_books ab WHERE a.id= ab.aid and ab.book_id=?

Это решит не только текущую проблему но и множество проблем в будущем. В частности с производительностью.

Включи отображение ошибок и бд сама скажет, что ей не так.

Плюс ты неправильно вставляешь переменную в запрос. Это никогда нельзя делать напрямую.

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$link = mysqli_connect($host, $login, $password, $database_name);
if (!empty($_POST['id'])){
  echo 'Вы ввели ' . $_POST['id'];
  $stmt = $link->prepare("INSERT INTO `single` (`id`) VALUES (?)");
  $stmt->bind_param("s", $_POST['id']);
  $stmt->execute();
}

?>

Чтобы отобразить ошибку mysqli prepare, достаточно той строчки, которая написана второй сверху.
Это единственное, что нужно для отображения ошибок mysqli. Ну и разумеется нужно настроить отображение ошибок РНР в целом.

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

function AddTable($data)
{
    global $DB;
    $query = 'INSERT INTO table (title) VALUES (?)';
    $stmt = $DB->prepare($query);
    $stmt->bind_param('s', $data['title']);
    $stmt->execute();
    return $DB->insert_id;
}

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

В класс, кстати, эту отдельно стоящую функцию запихивать не нужно.

Неужели сама идея реляционных бд с ООП несовместима?

Ты весьма недалёк от истины.
Некоторые сравнивают эту проблему с проигранной США войной во вьетнаме.

Решение от Victhor подходит для единичных выборок, но как быть с коллекциями? Люди начинают изобретать разные стратегии подгрузки - lazy loading, eager loading. Вот Елоквент, например, собирает в кубышку все айди загруженных товаров и потом пуляет 1 запрос с IN (...) чтобы получить для них бренды, которые потом в цикле пришпандоривает к товарам.

Но все это очень быстро начинает сказываться на производительности. И всё дальше затягивает нас в пучину Вьетнамской войны, или другими словами в кроличью нору Object-relational impedance mismatch - как по-научному называется озвученная тобой проблема. Дальше начинается совсем уж треш и угар, типа дико тормозащих коллекций в Доктрине или таких извращений, которыми занимался один мой знакомый - он плодил вьюхи в БД, поскольку его ОРМ умел работать только с одной таблицей.

Или все же модифицируются в дальнейшем классы, переписыванием кода?

В одном ты можешь быть уверен: такое легкое отображение, которое рисует тебе воображение при первом знакомстве с ORM - чтобы так хоба-хоба, и у нас записи из БД отобразились в объекты - увы, не существует. Да, приется переписывать, и много. И чем сложнее взаимосвязи, тем хуже будет работать автоматизация.

И тут на первый план выходит организация ORM и становится очевидной превосходство стратегии Data Mapper, когда слой работы с БД полностью отвязывается от объекта бизнес-логики.

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

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

И это мы сейчас говорим о read-моделях, и даже не трогали тему write models - то есть сохранения измененного объекта - со всеми гроздьями смежных объектов(!) - в БД!

Любую.
При 10 000 записях в секунду можно начинать что-то думать с железом.
А 20 записей в секунду это настолько ни о чем, что наверное даже sqlite потянет.

array_merge(...$result);

Надо понимать одну простую вещь. Что фреймфорк не создаёт за тебя приложение. Код, основанный на фреймворке, составляет от 1% до 10% от всего кода приложения. Все остальное - так называемую бизнес-логику - всё равно пишешь сам.

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

Фреймворк снимает с тебя рутину, стандартные модули типа авторизации или отправки емейлов. Но код твоего приложения он за тебя не напишет. Тут всё сам. И скилл собственно писания на РНР тут очень даже востребован.

Другое дело что когда учишь чистый РНР, то без вариантов учишь спагетти говнокод системы 1990-х годов. А хороший фреймворк ставит мозги на место, потому что одна из его функций - это правилно структурировать твоё приложение.

В общем, учи сначала пых а потом Симфони