ThunderCat

1) Для начала - не называть поля таблиц на румынском, используйте общепринятый стандарт - английские названия в нижнем регистре.
2) Читать про базы данных, выполнение запросов в пхп и понимать SQL на уровне "выбрать и отсортировать по полю".
3) Учить операторы for, foreach, while, понимать для чего и как их использовать.

В чем вопрос? При чем тут аякс и жквери? Делаете 2 соединения, присваиваете разным переменным ссылку на разные соединения - все. Когда нужно 1 бд - юзаете $bd1, когда второе - $bd2.

1) Четкая структура приложения, чтобы все модули работали по единой схеме(смотреть MVC как самую распространенную для пыха и самая понятная для новичков)
2) Объекты, почитать про solid и другие grasp.
3) Единая точка входа и понятный вменяемый роутинг
Тогда и только тогда разработка превращается из адского ада в приятный процесс написания красивого кода и обдумывания самых удобных/быстрых решений, вместо карябанья тонн фикалокода и тысяч строк дублей.
Ну и смотрите как что написано у серьезных проектов, гляньте внутрь какого-нть ларавел и фэтфри для начала.

самый простой вариант - хранить json, подходит в случае если у вас не будет происходить выборка из бд по этим полям, т.к. никакой индекс не даст нормального поиска по таким строкам, это оверхэд и не каноническое хранение. В идеале - отдельная таблица со значениями каждого набора как строки, связь по ключу с парентом(как заметили в комментариях - связь один ко многим).

echo curl?

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

Я смотрю здесь идет отбор на битву экстрасенсов )
Возьми за правило проверять действия пошагово если что-то не работает, для начала оставь только строку с редиректом, без ифа, далее логично проверить что попадает в условие проверки и тд.

Вообще связь от сервера к браузеру, а не наоборот не может быть установлена, т.к. технология хттп запросов этого не предполагает. Если есть четкая необходимость 100% ответа от сервера браузеру в момент обновления данных на сервере, существует 3 способа, из них вам тут настойчиво предлагают самый неверный.

1) Запрос аяксом по таймеру( грузит и сервер и клиент, выполняет кучу ненужных запросов, генерируя мусорный трафик)

2) Лонг поллинг запросы - упрощенно - на сервер идет 1 запрос от клиента, который имеет длинный таймаут, сервер держит это соединение открытым до момента когда на сервере появляются новые данные, после чего отдает в запрос эти данные и закрывает соединение, из браузера открывается новое соединение и тд. Искать тут или в гугле long polling.

3) Сокеты, в принципе это те же лонг поллы, только более оптимально обкатанные, обычно на soсket.io и node.js, которые умеют это "из коробки" и не требуют дополнительных настроек сервера как в случае чисто
пхп лонг поллов.

По всем трем видам море информации, можно смотреть статьи типа такой, весь функционал подробно разжеван.

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

Начнем с того что сжатия изображений без потерь не работает для уже сжатых файлов, например jpg, png, gif, за редким исключением, когда например гиф или пнг имеют меньшее реальное количество цветов чем задано в палитре. Речь идет о сжатии с потерями, которое хотя и не портит изображение до неузнаваемости, все же вносит серьезные искажения в картинку, как в цветовом плане, так и в плане "зернистости" и "артефактов". Приемлемый уровень сжатия индивидуален для каждого отдельно взятого изображения, и чаще всего отображается в условной шкале "качества" от 1 до 10 (иногда от 1 до 100, просто шаг искажений делают меньше), где 10 - очень малая степень сжатия и высокое качество, а 1 - полный фуфел, в котором не всегда можно угадать о чем вообще картинка. Соответственно, сжать все в папке не лучший вариант, с каждым проходом и пережатием качество падает, даже не смотря на то что мы выставим максимальное качество, через N итераций мы получим фуфло в чистом виде. По этому гугл определяет отношение размера картинки в пикселях к размеру в байтах и выдает рекомендации на основе статистики, сколько примерно должна весить такая картинка, +/- , пережимать или нет. Так что я бы не стал прям вот все картинки в папке так наивно под одну гребенку.

file_put_contents(__DIR__ . '/testfile.txt', 'Start ' + $_GET['id'], FILE_APPEND | LOCK_EX);
sleep(5);
file_put_contents(__DIR__ . '/testfile.txt', 'End ' + $_GET['id'], FILE_APPEND | LOCK_EX);

или накапливать данные в переменной, затем заносить скопом.

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

пхп ини настроить:
default_charset = "utf-8"

Как и везде, есть несколько путей, например:
* Крон каждые 10 минут, это будет не большая нагрузка и не думаю что игровая механика поломается если вещь продастся не через час, а через час и 5 минут.
* Не делать крон, а при очередном запросе списка вещей проверять на наличие "устаревших" шмоток и автоматически менять на деньги. Тогда нагрузка будет более выборочной, "размазанной" во времени, + у вас все равно будет запрос к шмотке, тут ее и обрабатывать, сэкономите кучу запросов и ресурсов.

Как связана отправка полей и вставка в базу?
(Ответ - НИКАК)