Is it a good practice to create a stored procedure that creates a user-defined function...?

I'm analyzing a fellow developer's SQL code and I could be totally wrong, but something they've done doesn't seem good to me.

The design is for a dynamic expression builder. The expressions are st开发者_开发技巧ored using a few tables and the system works. The aspect of the system that concerns me is that when the expression records are stored, a stored procedure is called that then creates a UDF that unrolls the entire expression as one function.

So what that means is, for each unique expression created, there will be a unique UDF that can be ran that will execute that expression. I'm assuming that this is being done so that the execution plan can be cached and performance will be increased, as opposed to building dynamic sql and running that each time.

What do you guys think, does it seem like an acceptable solution? Do you need more info?

This sounds like a recipe for disaster to me. The main reason would be if someone went back and cleaned up the UDFs (unless they are only used once, then your "execution plan" idea is shot) the software fails. And, if you don't clean up, you end up with a lot of clutter not used, especially after a lengthy period of time.

At further reading, it sounds like the UDFs are somehow stored as metadata, which sounds a bit better, but I am not sure you are saving that much once you consider all the extra clutter creating multiple UDFs creates. Is performance an issue?