There is no problem in that, implementation depends greatly on each one, resulting in a call within the PDO rules.
Of course, it depends on the project too, and for each one of us we will certainly have different approaches. I prefer almost always ... ok ... always ... using OOP / classes and objects and when implementing any template it is essential to use them nowadays. Also important is the semantics used.
Once again, not being the best form for the reasons I explained, I will start responding within the question template to make you think differently, so in your specific case of the update_tables would do the following:
function update_table($table, $collum, $id, $value) {
$db = conn();
$data = array(':value' => $value, ':id' => $id,);
$sql = ("UPDATE {$table} SET {$collum} = :value WHERE 'id' = :id");
try {
$st = $db->prepare($sql);
$st->execute($data);
return true;
} catch (PDOException $e) {
return false;
}
}
Implementations may vary, but what I am going to do here is to explain the following:
The name of the update_table method may be different because it is important to reduce writing whenever possible, but to make it logical within the context. It will always be an UPDATE to TABLE in this case.
Changing $ id is also important because the concept has table orders > column will come the identifier, etc.
Adding some added value to the function is also important. Knowing, for example, if you updated well or did not even update ... for that purpose you just need to return true or false . By encapsulating the possible errors that may happen we are also avoiding many try and catch throughout the project.
In an UPDATE it is normal to try to understand if we update one or more items but this depends on the required logic.
It makes sense to use functions in order to simplify our life as programmers, but when we do it we have to do it in a more comprehensive way so we can "almost" text that tells us everything when we read our code.
Context, naming, validating possible errors, and returning the result are important.
By ending, say that in relation to the code that is built for use throughout a project the documentation is essential .