Replace trivial computation with PL/SQL Function?

Question

I have several queries that are computing integral day differences based on an Oracle date field -- for example, something along the line of:
select
Customer
, trunc(current_date) - trunc(payment_date)
from
( select 'Fred' Customer, to_date('2009-06-01 07:05:00', 'yyyy-mm-dd hh24:mi:ss') as payment_date from dual union all
select 'Barney', to_date('2009-07-01 15:15:15', 'yyyy-mm-dd hh24:mi:ss') from dual
-- Customer Account_Age
-- Fred 49
-- Barney 19
I have a developer that is now advising that we use a PL/SQL user defined function rather than the difference of these TRUNC functions. That goes against the grain for me. In the MS SQL Server Transact SQL forums I would almost never recommend replacing a trivial expression with a user defined function because the UDF gets called for each row returned by the query and adds overhead to the query.
Does the same kind of logic apply to Oracle UDFs? Is it a good idea to replace trivial calculations such as this with UDFs?
Kent Waldrop

Answer 1

Kent Waldrop wrote:
Would you use the function instead of the inline calculation if it were not a large data warehouse but the target number of rows was in the millions?That would depend...
- What are the odds that the business will change the definition of this calculation? The more likely it is to change, the bigger the benefit to centralizing it.
- How many places is the calculation repeated today? Is that likely to increase over time? The more it is repeated, the bigger the benefit to having one standard place for it.
- Is this going to be a calculation that gets reimplemented in a variety of reporting tools, in SQL, in applications, etc? Again, this goes to the size of the benefit.
- What are you doing with the results of the SELECT statement? If you're using it in an INSERT ... SELECT, you're more likely to notice the performance overhead than if you've got a FOR loop that is doing row-by-row processing.
- How critical is performance of this query? If you're processing millions of rows but that is happening in the dead of night, perhaps adding a few minutes to the run is well worth the improved maintainability.
Different people, working on different systems, will weight these factors differently and come to different conclusions. Either solution is defensible under the right circumstances and there's a large middle ground where both are reasonable to most people. Steven Feuerstein, one of the most well respected PL/SQL gurus, would push strongly for a function in almost all cases. Most of the commentators here would tend to lean toward the performance benefits of putting the calculation in SQL.
Justin