Adamos

mPDF позволяет положить исходный PDF фоном и сверху (по координатам) налепить добавки.
Но для произвольного PDF вы просто не будете знать, что куда положить.

Стоит вернуться к задаче и пересмотреть ее. Откуда берется PDF у пользователя? Если это бланк, который он каким-то образом заполняет, а вы добавляете свою информацию - нужно просто дать ему форму на сайте, собрать его данные, добавить ваши и генерировать из них окончательный PDF.

Ваш класс БД будет работать с таблицами. Зачем ему лезть в файлы? Его задача (и единственная ответственность) - прослойка между кодом, который обращается к БД, и кодом, который реализует хранение. Не нужно в него совать куски ни из того, ни из другого.
Сделайте таблицу отдельным классом, который принимает имя файла в конструкторе. В нем уже читайте и пишите данные в файл.
Сделайте фабрику, которая по имени файла выдает класс таблицы-файла либо создает его, проверяя наличие такого имени в системе и инкапсулируя в себе ВСЮ логику имен файлов, путей и проч. Классу БД об этом знать незачем, классу таблицы - тем более.
В общем, делите код на то, что надо сделать вот здесь на этом уровне логики, и выкидывайте из него все, что требует опуститься на уровень ниже, в соответствующие классы. И работайте только с их методами, не вникая в реализацию. Не размазываете реализацию конкретных вещей по коду - собирайте ее в одно место, и пусть за нее отвечает только один класс.

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

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

Альтернатива БД, если лог именно и только для разработчика.

class Logger
{
	private $logfile;
	private function __construct()
	{}
	public function __destruct()
	{
		$this->log('');
		fclose($this->logfile);
	}
	public function log($string)
	{
		fwrite($this->logfile, $string . "\n");
		fflush($this->logfile);
	}
    static public function getCommon($tag)
    {
        $logDir = base_path() . '/../logs/' . $tag; // это в Ларавели, без нее $_SERVER['DOCUMENT_ROOT'] или абсолютный путь (если должно работать в консоли/кроне)
        if(!file_exists($logDir)) {
            mkdir($logDir);
        }
        $logger = new Logger();
        $logger->logfile = fopen($logDir . '/' . date('Y-m-d') . '.log', 'at');
        $logger->log(date('Y-m-d H:i:s') . "\n");
        return $logger;
    }
}

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

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

д'Артаньян / О'Брайен
ван Вейден / ди Каприо
Щекочихин-Подъяченский (кстати, тут в транслите тоже будет апостроф)
И. Ньютон и просто Платон
П. Д. Х. Ф. де П. Х. Н. М. де лос Р. С. де ла С. Т. М. П. Руис-и-Пикассо :)
J. Nesbø, наконец

В целом, регулярка для ФИО - это максимум временный инструмент для выковыривания того, что получилось, и доводки руками.

Перебрать исходную кашу. Набрать массив

[14] => [A2, A7,  A8, A9, A10],
[15] => [A9],
[17] => [A1, A2, A4, A6, A8, A9],
[18] => [A1, A2, A4, A6, A8, A9],
[32] => [A5, A7, A9],
[33] => [A5, A7, A9],

...
И объединить ключи у тех, у которых одинаковый набор значений.

https://stackoverflow.com/questions/2994819/php-st...

<?php FixMoney($data[$user['cash']]) ?>
Смотрим в хрустальный шар... внимательно смотрим... ВИЖУ!!!
<?php FixMoney($data[$user]['cash']) ?>

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

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

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

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