ddf1f8b1   
   XPost: microsoft.public.sqlserver.server   
   From: geoffxx@softwareobjectivesxx.com.au   
      
      
      
   Basically the DBA is engaging in some self-serving spin. Less kind   
   circles would call it wanking.   
      
   UDFs have some positive benefit in that they encapsulate business logic   
   and thereby promote consistency in column calculations and allow   
   flexibility. Create a UDF and maintain it from a central place and use   
   it everywhere. Need to change the business logic? Do so in one place.   
      
   But as others have explained, there is a cost. The cost is performance   
   overhead in that the UDF is evaluated for each row. So if your recordset   
   returns 1000 rows the cost is (probably) trivial. Return a million rows   
   and you may have to drink a lot of coffee while you wait.   
      
   Sometimes the complexity of the business logic screams out for a UDF   
   simply so that further selects are simple and easy to read/write. There   
   is no right or wrong way: it all depends on the context of the   
   implementation. The simple rule of thumb is to try something two ways.   
   Measure both and pick the most efficient.   
      
   Cheers,   
      
   Geoff Schaller   
   Software Objectives   
      
      
      
   "bill"  wrote in message   
   news:19b7e7b6-607b-4e8f-8dc0-7f1c5ced4307@j32g2000yqh.googlegroups.com:   
      
   > teddysn,   
   >   
   > I'm a little confused about the client's concern.  From the first   
   > message:   
   >   
   >  "... They are now quibbling about the cost of the second   
   > batch, and their DBA has come back with some suggestions for keeping   
   > down costs..."   
   >   
   > Do they mean query cost?  If so, the UDF's they are suggesting are   
   > definitely not the way to go, as they will make the queries more   
   > expensive (take longer).   
   >   
   > Do they mean monetary cost?  That seems weird to me, because I can't   
   > see that typing out a join vs invoking a UDF is going to take   
   > materially more or less development time.   
   >   
   > My experience with tables valued UDFs (even multi statement ones) is   
   > consistent with the article cited earlier, i.e. table-valued UDF's are   
   > fast.   
   >   
   > I confess to never having used a scalar UDF.  I don't see the point.   
   > It's easy enough to just do the requisite join, inline function, etc   
   > and actually seems to be a more natural way to code.  I suppose if I   
   > had some tricky mathematical transformations being repeated all the   
   > time a scalar UDF might be useful, but I haven't run into those   
   > situations.   
   >   
   > Exactly how did the client's DBA feel UDF's would decrease cost?  I'm   
   > not asking that question to be a dork, but because I don't understand.   
   >   
   > Thanks,   
   >   
   > Bill   
   >   
   >   
   > Thanks,   
   >   
   > Bill   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)