boronick

Храните данные в базе это хранилище, а код выполняйте в скрипте.

Прежде чем всё это усложнять описанным вами способом, необходимо определиться с ожидаемыми количествами. Насколько много всего будет переменных, насколько много может быть этих объектов, какие ожидаются частоты этих ваших обращений.
Ещё нужно определиться как вы планируете редактировать наборы изменяемых переменных. Запишете прямо в БД руками, или нужно делать API для редактирования списков?
Вы собираетесь скрипт запускать при каждом поступлении новой порции данных? Может правильнее запустить его на ожидание порций из пайпа? Или АПИ сделать поверх http.

По существу вопроса. Минус хранимых процедур в том, что это код, который хранится вместе с данными. Нужно делать отдельные специфические "приседания", чтобы правильно деплоить и обновлять такой код, хранить его в системе контроля версий, мигрировать от версии к версии...
Быстродействие в обоих случаях будет зависеть от конкретных действий, которые вы будете каждый раз повторять при "обращениях". Однако при наличии "бутылочного горлышка" в этом месте при реализации через хранимые процедуры вы уже мало что там можете сделать. А вот в коде на питоне можно при необходимости добавить воркеров и таски на длительные операции передавать им через очередь.

В целом задача звучит так, будто делать её надо максимально простым способом без предварительной оптимизации, которая, скорее всего, и не пригодится. Оптимизировать нужно по факту, когда понятно станет где будут проблемные места.

а можно в отдельной таблице, но это накладнее.

Ошибка тут.

что эффективнее: хранить в записи список id объектов, которые должны быть обработаны при обращении к этой записи, в виде строки (скрипт будет парсить строку и отрабатывать каждый id), либо сделать триггер и хранимую процедуру (MySQL), которая возьмёт эту работу на себя?

Ни то ни другое.

Если тебе нужна канава, и есть экскаватор, то взять из его ремнабора лопату и ей копать канаву - голимая дурь. Это что касается обработки в скрипте - сервере БД сделает то же на порядок быстрее и эффективнее.

Но есть ещё косяк - в том, как хранятся данные. Упаковка набора данных в одну запись в виде CSV-списка - это тоже дурь в подавляющем большинстве случаев. Умные люди не зря придумали нормальные формы, которые позволяют обрабатывать данные максимально эффективным образом.

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

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