Adamos

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

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

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

0. Имеете В - массив массивов вариантов.
1. Создаете П - массив текущих позиций в каждом массиве (инициализируя их все нулем).
2. Сохраняете (или выводите) текущую комбинацию - for(i) В[ i ][ П[ i ] ]
3. Проходите циклом по П от 0 до конца, находите позицию, которую можно увеличить, обнуляете все, которые до нее.
4. Если это удалось сделать - возвращаетесь на шаг 2.
Так получается не более одного вложенного цикла.

algolist.ru/maths/combinat/index.php

Таблица products (изделия):
id - title - article - прочие общие поля, которые будут у любого изделия

Таблица properties (типы свойств):
id - title - прочие поля, нужные для обработки (например, это может быть json-поле, в котором прописаны нюансы отображения. Поиска по нему все равно никогда не потребуется)

Таблица product_properties (свойства изделий):
id - product_id - property_id - property_value (строковое значение достаточной длины, чтобы его хватило на что угодно)

Если постоянно нужен поиск по значениям свойств и список возможных значений того или иного свойства - можно ввести еще таблицу property_values:
id - property_id - value c уникальным индексом по двум полям
и в таблице product_properties вместо property_id и property_value задавать property_value_id

Колхоз на коленке:
- таблица: id - слово (уникальный индекс)
- таблица: база товара (1 или 2), артикул (индекс), id слова в таблице слов.
Для каждого товара из каждой базы разбиваете название на слова, для каждого из них делаете запись в обеих таблицах. Получится несколько миллионов записей, это не так страшно и не так долго, если не косячить с запросами.
Потом по артикулам первой базы запрашиваете артикулы второй, у которых во второй таблице больше всего записей с id прописанных для первого артикула слов. Из десятка лидеров выбираете вручную сопоставление.

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

Можно конкретно для вашего кейса искать закономерности вроде того, что отчество, если оно есть, никто не произнесет иначе, как после имени. И у русских оно обычно определяется по окончанию -вич/-вна. Ну, и по базе имен определяете, что может быть именем. А если не получилось - так, может, просто переспросить? У вас же интерактив ;)

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

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

Регулярки пишутся не для "вообще", а для определенной цели. Например, проверки, что введенный адрес соответствует неким требованиям.
Кстати, проблемы корректности адреса никакими регулярками не покрываются.

На пальцах: когда вы открываете РНР-страницу, веб-сервер выделяет память и запускает в ней ваш скрипт. Когда вы открываете другую страницу - выделяется другая память. Никакого взаимодействия "на лету" между ними нет и быть не может.

Вы любите играть?
Удалите Винду - и у вас появится мощный стимул изучить Линукс, чтобы запустить на нем игрушки ;)

SVG как раз остается кликабельным. Просто он становится меньше вставленной в него картинки, а по ней щелкать, естественно, бесполезно.
Нужно закопать этого кадавра и сделать либо полноценный svg с реально отрисованными областями, либо ставить картинку без svg-обертки. Зачем она тут?

let buttonsOperations = document.querySelectorAll('input[type=radio]:checked');
if(buttonsOperations.length > 0) {
        calculatorOperator(buttonsOperations[0].getAttribute('data-operation'));
} else {
        output.innerHTML = '<strong>Ошибка!</strong> Арифметическая операция не выбрана.';
}

Поставил и забыл. Проблемы - если только с поломавшимся железом. В отличие от винды, которая через полгода использования становится тормозной помойкой.
Не требуется постоянное обновление железа вслед за требованиями Редмонда. У меня большая часть подопечных сидит на Core2Duo и не жалуется. У некоторых до сих пор Pentium4. Новых i3/i5 - считанные единицы, в очередную закупку планирую Ryzen3, разницы в работе все равно нет, а по цене проц+мать+память+SSD выходят в сумме 14 тысяч. Смысла добавлять к этому червонец за Винду, чтобы потом с ней корячиться, не вижу совершенно.

Перемены, на самом деле, у многих назрели не только в системе, но и в самой организации работы. Многим фирмам давно пора выкинуть Винды и перестать мучить Ёксель, внедрить нормальную CRM - и работать на чем угодно, лишь бы браузер запускался...

"Ну конечно, естественно, само собой разумеется - нет!" (Гэндальф в русском переводе).
Эта область называется "инкапсуляция", и это самые азы архитектуры.

Вот тут часто спрашивают - а нужно ли программисту высшее образование?
Так вот, на нашем строительном факультете половина курса английского была таки заучиванием терминов по словарю.
Транслит ужасен как в том, что плодит ошибки при написании, так и в том, что вынуждает читающего постоянно "переключать контекст" с языка программирования на русский, да еще вычитывать дикие конструкции типа borzhch вместо беглого чтения.
Вы можете довольно вольно использовать неточные слова и откровенный пиджин - главное, чтобы вы понимали написанное без вглядывания и человек, который читает ваш код, вас за это не проклял. Nothing else matters.
Беспокоиться об индусах, которым когда-нибудь случайно попадет в руки ваш код, вы все равно всерьез не будете.