PHP in database: bad practice but Lots of times here I've been told that using views custom php fields, filters or others is a bad practice, because putting php in the sql is dangerous.

My question is, if you only call to a function, that you defined in a module, is it still as bad?

Sometimes, especially for Views, making a custom handler, or, other example, a custom token, can be really heavy.
What are the risks if I make a custom field that only calls a function? Is it as dangerous and "forbidden"?
Here's my take on it:

The PHP docs says about eval:


  Its use thus is discouraged


It is always, let me emphasize that again, always, bad to use the PHP module (technically eval, but the PHP module makes a dangerous language feature much worse).

Details discussed in this question: What are the downsides of using PHP Filter code in blocks, nodes, views-args, etc?

The link provided by Clive claims 


  Sometimes eval is the only/the right solution.


It is possible that this is true, some times, but during quite a few years of professional development, I have never stumbled across a real need for it, in PHP or other languages.

Personally, I've taken it to the level that my servers disable the functionality on the php level itself, with disable_functions = eval.

With that said, on a small personal website, it's likely of less consequence than on a large enterprise one, and there are cases where it's at least not completely horrible to use it.