Accessing a database record requires some processing. What is better: to process in the script that called, or in a stored procedure in the database?

Question

MySQL

In short, the question is what is more efficient: store in the record a list of id objects that should be processed when accessing this record, as a string (the script will parse the string and process each id), or make a trigger and a stored procedure (MySQL), who will take over the job?

The details are like this. Python script for dedicated server + MySQL database. The script receives a request to process a record from the main table. Processing includes incrementing a number of variables of the user accessing the record. There is a table where for each variable a threshold value is set and an action that is performed when the threshold is reached. Each entry only affects some variables (slightly). IDs of variables that are subject to incrementation can be stored in one line in the record itself, or in a separate table, but this is more expensive. Question: from the point of view of performance, work out these variables (increment, check the threshold, upon reaching - the formation of an action request) in the receiving Python script or in a stored procedureon the trigger forces of a DBMS? (A related problem: can the stored procedure parse the string into IDs, and if not, will you have to store all this in another table <record_id-variable_id>?)

Answer 1

Before complicating all this in the way you described, it is necessary to determine the expected quantities. How many variables there will be, how many these objects can be, what frequencies of your calls are expected.
You also need to decide how you plan to edit sets of variable variables. Will you write it directly into the database with your hands, or do you need to make an API for editing lists?
Are you going to run the script every time a new piece of data arrives? Maybe it's more correct to run it waiting for portions from the pipe? Or make the API over http.
On the merits of the question. The disadvantage of stored procedures is that this is code that is stored along with the data. You need to do separate specific "squats" in order to correctly deploy and update such code, store it in the version control system, migrate from version to version...
The speed in both cases will depend on the specific actions that you will repeat each time you "request ". However, if there is a "bottleneck" in this place, when implemented through stored procedures, there is little you can do there. But in the python code, if necessary, you can add workers and transfer tasks for long-term operations to them through the queue.
In general, the task sounds like it should be done in the simplest possible way without preliminary optimization, which, most likely, will not be useful. You need to optimize after the fact, when it becomes clear where the problem areas will be.