tags:

views:

48

answers:

1

Hello, I have two T-SQL scalar functions that both perform calculations over large sums of data (taking 'a lot' of time) and return a value, e.g. CalculateAllIncomes(EmployeeID) and CalculateAllExpenditures(EmployeeID).

I run a select statement that calls these and returns results for each Employee. I also need the balance of each employee calculated as AllIncomes-AllExpenditures.

I have a function GetBalance(EmployeeID) that calls the two above mentioned functions and returns the result {CalculateAllIncomes(EmployeeID) - CalculateAllExpenditures(EmployeeID)}. But if I do:

Select CalculateAllIncomes(EmployeeID), CalculateAllExpenditures(EmployeeID), GetBalance(EmployeeID) .... the functions CalcualteAllIncomes() and CalculateAllExpenditures get called twice (once explicitly and once inside the GetBalance funcion) and so the resulting query takes twice as long as it should.

I'd like to find some better solution. I tried:

select alculateAllIncomes(EmployeeID), AS Incomes, CalculateAllExpenditures
(EmployeeID) AS Expenditures, (Incomes - Expenditures) AS Balance....

but it throws errors:

Invalid column name Incomes and

Invalid column name Expenditures.

I'm sure there has to be a simple solution, but I cannot figure it out. For some reason it seems that I am not able to use column Aliases in the SELECT clause. Is it so? And if so, what could be the workaround in this case? Thanks for any suggestions.

+4  A: 

Forget function calls: you can probably do it everything in one normal query.

Function calls misused (trying for OO encapsulation) force you into this situation. In addition, if you have GetBalance(EmployeeID) per row in the Employee table then you are CURSORing over the table. And you've now compounded this by multiple calls too.

What you need is something like this:

;WITH cSUMs AS
(
SELECT
    SUM(CASE WHEN type = 'Incomes' THEN SomeValue ELSE 0 END) AS Income),
    SUM(CASE WHEN type = 'Expenditures' THEN SomeValue ELSE 0 END) AS Expenditure)
FROM
    MyTable
WHERE
    EmployeeID = @empID --optional for all employees
GROUP BY
    EmployeeID 
)
SELECT
    Income, Expenditure, Income - Expenditure
FROM
    cSUMs 

I once got a query down from a weekend to under a second by eliminating this kind of OO thinking from a bog standard set based aggregate query.

gbn
I'd give you a million points for the OO encapsulation comment. Relational databases do NOT perform best when you try to use OO programming rules.
HLGEM
The reason why I have those two things in functions is that the calculations are fairly complicated and I need the result in many other different select statements throughout the app. So it made sense to me to write the functionality just once and then reuse it. I think I'm not the only one who hates to rewrite the same code all the time. If the scenario would be like you indicated (just a simple select with a CASE statement) to get the result, I wouldn't have written a function for it. But it's not the case.
Trex
@Trex: OK, then. Accept slow performance then to avoid optimising for a set based operation. It's as simple as that
gbn
I don't understand. So what are you saying is that I have to rewrite the same code in every query that needs it in order to get better performance? If that's the only way how to get better performance I may as well do it. I just want to be sure that that's what you are saying...
Trex
@Trex: not in every query: only where you have to run it over many rows. For a single employee then I'd leave it in a UDF
gbn