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

можно процедуру написать и дернуть ))

Я это к тому, что не понимаю, почему у вас выходит время за рамки выполнения скрипта )

SUM

плагины можно выносить в пакеты, зачем эти страдания? ОО

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

так мне его еще написать нужно

Если сложная аналитика, то уж точно это не надо вешать так ))

я бы в таком случае возложила эту обязаность на саму БД

ага, чтобы еще и бд положить к чертям :) че б и нет

да ладно))

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

делая сложные запросы из под орм или еще чего ты не положишь, а тут вдруг

Блин, пойду проржусь )

я конечно хз как это у вас происходит в богомерзком екоме, но к примеру, чтоб написать бандл для симфони тебе нужно саму симфони в бандле зареквестить в дев-завсимости

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

но когда кто-то будет реквестить твой бандл себе, то он получит только твой код, а не код всей симфони в придачу

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

я знаю, это подтверждает мою мысль - мы не знаем контекста автора
может ему достался громадный проект в наследство, а может он сделал неоптимизированный запрос

Нее, просто я пока не знаю ни одного артиста с миллиардом работ ) Это так, хреновая шутейка