ThunderCat

date('z',strtotime('31.12.2001'));
или проверить на високосность, параметр "L".

Да, так и должно быть, никто не может угадать заранее что и как вы будете запрашивать, по этому запрос ВСЕГДА возвращает массив, в случае если результат не пустой. Соответственно ваше значение будет в $res['name']; в случае построчного чтения результатов запроса, или $res[0]['name']; в случае получения массива целиком.

onsuccess?

1) установить вывод ошибок в индексном файле/единой точке входа:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

2) читать ошибки во вкладке нетворк.

1) Не надо называть контроллером то, что им не является.
2) Если у вас 2 дб - не надо в одном объекте их инициализировать, нужно создать 2 объекта (по 1 на дб) со своими настройками.
3) WHERE id - просто шикарное условие.
4) $_POST, $_GET и вообще сырые данные приходящие с фронтенда в запросы вставлять категорически нельзя. Во первых их надо хотя бы базово валидировать, во вторых для этого есть prepared statements.
5) Чем вообще обусловлено разделение данных на 2 базы? Похоже что вы что-то не так делаете изначально, на уровне проектирования структуры данных.

в мускуле не допускается использование таблиц из delete в подзапросах (емнип как и в других РБД).
Как вариант - обернуть запрос в дополнительный селект, тем самым организовав временную таблицу для внутренней выборки.
На будущее, для лучшего понимания проблем в запросе:
1) Аккуратно форматируйте запрос, разбивая на строки каждую конструкцию из запроса.
2) Следите за номером строки выдаваемом в ошибке запросов, так вам будет легче локализовать проблему.
3) Крайне не желательно вывод ошибок осуществлять на русском, старайтесь использовать англоязычные инструменты. Это позволит быстрее находить ошибки по тексту, не путаясь в переводах.

Идея на троечку с минусом.
Во первых нарушает 3 нормальную форму,
во вторых требует модификации сторонних "чистых" сущностей, размазывая логику
в третьих - если у человека 10 диалогов - какой из них вы будете писать в МОЙ лист верхним?

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

Коротко - для ПРОГРАММИРОВАНИЯ нужна арифметика на уровне корень/степень, перевод между системами счисления, понятие о типах данных, что входит в алгебру в разделе теории множеств чисел(школьный курс ее охватывает), и может еще что-то из мелочи, все это дают в школе.

Для решения НЕКОТОРЫХ задач (на самом деле достаточно широкого круга задач программиста) вам нужно будет знать уже гораздо больше, например сложность алгоритмов(теория алгоритмов и данных, частный раздел дискретной математики), теория графов (для структур данных чуть сложнее чем табличка в екселе), в модном и перспективном нынче биг дата и дата сайнс, где легко и непринужденно подключается как базовый матанализ, так и теорвер с диффурами, про крипто направление вообще молчу, там вообще половина современного матаппарата наверное используется. Игры в большинстве случаев делаются на готовых движках, но базовую тригонометрию все равно надо будет вспоминать, а местами и интегралы.

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