FanatPHP

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

Вот здесь можно посмотреть нормальный пример
Сначала запрос надо подготовить , поставив вместо переменных знаки вопроса, а потом выполнить, передав переменные отдельно

<?php
$login = $_POST['login'];
$email = $_POST['email'];
$password = $_POST['pass'];
$conn = new PDO('mysql:host=localhost; dbname=testbd', 'root', '', [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);

$sql = "INSERT INTO users (login, email, password) VALUES (?,?,?)";
$stmt= $pdo->prepare($sql);
$stmt->execute([$login, $email, $password]);

И все всегда будет работать

По сслыке есть все ответы.

Если использовать позиционные "псевдопеременные", то просто смержить два массива - один для in, второй для not in.
Если использовать именованные "псевдопеременные", то сначала приготовить два массива, с разными именами переменных, а потом просто их смержит.

$user = 'andrey';
$stmt = $conn->prepare("SELECT * FROM table WHERE user=?");
$stmt->bind_param("s", $user);
$stmt->execute();
$result = $stmt->get_result();
$data = $result->fetch_all(MYSQLI_ASSOC);
echo json_encode($data);

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

$conditions = [];
$parameters = [];

// conditional statements
if (!empty($_GET['name']))
{
    // here we are using LIKE with wildcard search
    // use it ONLY if really need it
    $conditions[] = 'name LIKE ?';
    $parameters[] = '%'.$_GET['name']."%";
}

if (!empty($_GET['age']))
{
    // here we are using equality
    $conditions[] = 'age = ?';
    $parameters[] = $_GET['age'];
}

$sql = "SELECT * FROM users";

// a smart code to add all conditions, if any
if ($conditions)
{
    $sql .= " WHERE ".implode(" AND ", $conditions);
}

// the usual prepare/bind/execute/fetch routine
$stmt = $mysqli->prepare($sql);
$stmt->bind_param(str_repeat("s", count($parameters)), ...$parameters);
$stmt->execute();
$b = $stmt->get_result()->fetch_all(MYSQLI_ASSOC);
if($b) {
    print_r($b);
} else {
  echo "0 results";
}

Ошибка 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 - то есть сохранения измененного объекта - со всеми гроздьями смежных объектов(!) - в БД!

array_merge(...$result);