FanatPHP, ну тогда мне как бы непонятно, что мешает собственно сразу в этом JSON не сформировать готовый WHERE... тем более что тот самый клиент лучше всех знает, что он хочет получить.
И тогда в PHP ничего и декодировать не надо, прямо прилепляем полученное условие в запрос - предварительно жёстко проверив его на отсутствие инъекции, конечно.
FanatPHP, тогда вообще непонятно, за каким нужен промежуточный JSON. Или, если передача должна состояться именно в таком формате и никак иначе - то, в общем, какая в пень разница, как он будет выглядеть, этот JSON? главное, чтобы построенные правила его формирования в принципе не допускали неоднозначной интерпретации.
Правильная настройка безопасности браузера (белый/чёрный список) и файрвола (список приложений, которым разрешено гулять в Инет). Правильная настройка локальных политик безопасности.
Ну и, само собой, учётная запись не должна иметь избыточных прав - и особенно должна не быть членом группы локальных администраторов.
В каком именно виде этот "словарь" попадает к MySQL?
В общем, вместо тупого INSERT .. VALUES следует использовать INSERT .. SELECT, а в SELECT-части выполнить парсинг переданного значения на отдельные элементы (например. рекурсивным CTE).
FanatPHP, а мне больше всего понравилось намерение конвертировать текстовый формат хранения данных в язык программирования (на самом деле, конечно, в язык запросов, но это детали). Вот думаю - а вдруг получится?
valeriy_good, оконная функция является не агрегатной, а скалярной. Но особого типа - она выполняется не на исходном наборе данных, а на итоговом, полученном после группировки и пост-отбора. Так что никакого "оборачивания" тут нет и в помине. Вас сбивает с толку однотипность функций и общее имя - постарайтесь поскорее от этого избавиться.
Да хоть два раза... кто мешает хранить какую-нить фигню типа