Leaderboard

The correct way to do it is use a JOIN in a query when you need the reqid, not to duplicate values from one table into another.

That doesn't really say a whole lot. I think what you're doing is essentially logging: when a piece of code performs some action, you want to record a log of the fact that it happened, as well as potentially some supplemental information about it. For example, you've got this "new comment" thing. That sounds like a log message. Additional information about that could be the author of the comment, what they were commenting on, and the timestamp of when they made it. If you just want something that lives for the duration of the code - you don't want this going to a file, or saved to a database, or anything persistent like that - then some parts might not be as useful as others (like the timestamp). Consider this simple function: function log_message(string $message, array $data = []) { $output = date("[Y-m-d H:i:s] ") . $message . PHP_EOL; foreach ($data as $key => $value) { $string = is_scalar($value) ? $value : json_encode($value); $output .= "\t{$key} = {$string}" . PHP_EOL; } file_put_contents("/path/to/file.log", $output, FILE_APPEND | LOCK_EX); } used like log_message("New comment", ["author" => $authorId, "page" => $pageId]); Instead of building up some "debug" string living in a class somewhere, you call that function and it will immediately write the message to a file. You can then open that log file (remember to change the path) in any decent editor and watch messages get written to it when you browse your site. There is actually some better stuff that's built-in to PHP you can use, so the above is really more of an example of the concept of logging. Does that make sense? <opinion> PHP is a functional language, meaning it has functions that don't have to live within classes. It makes sense to occasionally use functions for things that don't need to belong in a class - such as that "log_message" above. The one disadvantage is that PHP can't (yet) autoload functions like it can classes, so in order to get them available everywhere you need to make sure the file(s) with the functions are always included; normally a site has a single entrypoint file, like /index.php, through which all requests pass, and that would be a great place to include the necessary files. A similar approach is static methods in a class: it's kinda object-oriented in that there's a class, but really the class is just a container for functions. A container that can be autoloaded by PHP. And with static methods, you don't have to pass around these "util" (or "pass"?) objects everywhere. That's a reasonable compromise, but I'm not thrilled as (a) it's just an end-run around plain functions and (b) it lends itself to organically-grown utility classes. So really, the first step to getting rid of a utility class is to decide whether the functionality you have doesn't actually have an appropriate and specific class for the various methods after all. Consider the log_message function having been added to a Utility class. You might start with it as a regular (non-static) method on a Utility class. Then you realize that you can make it static, as you don't really need an instance of the Utility class in order to write some stuff to a file, however it's still a "utility". The next step is to realize that logging is a concept which can have its own class. Like a class named Log, or Logger. That's better than a utility as you've taken a specific requirement (log a message) and found a specific class (Thing That Logs Messages) for it to belong in. (And there's more to think about after that...) But occasionally you do end up with functions that don't really belong anywhere. For example, I have some code that needs to check if an array contains an item matching some conditions, as determined by an arbitrary function that returns true/false. function is_even_number($number) { return ($number % 2) == 0; } PHP doesn't have a built-in function that can do what I need, so I have my own called "array_contains". function array_contains(array $array, callable $function): bool { foreach ($array as $key => $value) { if ($function($value, $key)) { return true; } } return false; } used like array_contains([1, 2, 3], "is_even_number") // true array_contains([1, 3, 5], "is_even_number") // false I'm not going to create an Array class just so I can put this function into it, and for reasons that are more complicated than I need to get into here. So it's just a plain function. </opinion> Point is, there are two main alternatives to a utility class: (1) go ahead and use a plain function because that's how PHP works and it's totally fine that not every single thing in PHP is an object, or (2) conclude that a particular thing could actually make sense in a separate, dedicated class because there's potentially more to the general concept that you might want to account for in the future.