|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:42 AM
Points: 1,072,
Visits: 1,026
|
|
forjonathanwilson (7/21/2010) A calculated field is not going to be A+B, because thats just a stupid test case. More likely a computed field will be connected to a UDF and be gathering data from elsewhere.
Not in my experience! Computed columns are often used in data warehousing for mundane things like FullName and Age, two examples mentioned by others in this discussion.
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Friday, November 09, 2012 12:51 AM
Points: 429,
Visits: 187
|
|
We use them here for Total Calculations using UDF functions. But since we are developping the application, we are beeing very careful that they are only used when there aren't too many columns returned...
For example, When calling an invoice.
Otherwise we use views for reporting purposes.
Not sure if this is recommended or not. But this is how it is done here and now they are starting to use LINQ... Not familiar with it. I might try to understand it and create a new question?!?!
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Friday, November 09, 2012 12:51 AM
Points: 429,
Visits: 187
|
|
oops... meant number of rows returned...
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Yesterday @ 1:10 PM
Points: 2,673,
Visits: 2,418
|
|
| Good one....got it wrong....I have to do some more reading.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 2:03 AM
Points: 3,046,
Visits: 1,307
|
|
jghali (7/21/2010) We use them here for Total Calculations using UDF functions. But since we are developping the application, we are beeing very careful that they are only used when there aren't too many columns returned...
I think it's more likely to be the UDFs (assuming they are scalar) that are the problem with many rows, since UDFs are calculated for each row, effectively making the query incur a cursor-like performance penalty. This is a problem I frequently run into when investigating slow queries on large numbers of rows.
You can reduce ore eliminate the negative effect either by persisting and indexing the computed column (assuming the UDF is deterministic) or by using a different method. Using a view won't help if the view contains the same scalar UDF as the computed column.
Duncan
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 2:53 AM
Points: 1,529,
Visits: 359
|
|
agree completely, we use computed columns for getting the full name from firstname, lastname combination...
wware (7/21/2010)
forjonathanwilson (7/21/2010) A calculated field is not going to be A+B, because thats just a stupid test case. More likely a computed field will be connected to a UDF and be gathering data from elsewhere. Not in my experience! Computed columns are often used in data warehousing for mundane things like FullName and Age, two examples mentioned by others in this discussion.
|
|
|
|
|
SSCoach
         
Group: General Forum Members
Last Login: Monday, May 20, 2013 1:07 PM
Points: 18,733,
Visits: 12,332
|
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 4:52 PM
Points: 1,379,
Visits: 2,626
|
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Today @ 1:02 AM
Points: 10,989,
Visits: 10,534
|
|
How many check boxes are too many? 
"The engine tweaks to be performant."
I ticked that.
Paul
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 4:33 AM
Points: 5,241,
Visits: 7,049
|
|
jghali (7/21/2010) Sorry about the ambiguous answer.
What I was trying to get to is...
Retrieving data from a normal column is much faster then having to calculate the value every time a computed field is called. Can you imagine, if you are calling 100 000 rows including a computed column? It would definitely take more resources specially if the computed column comes from other tables via UDFs... Hi jghali,
First, thanks for contributing a question, in spite of the harsh comments so often targeted at QotD contributers. Please submit more in the future!
On your (rhetoric?) question: "Can you imagine, if you are calling 100 000 rows including a computed column? It would definitely take more resources (...)" (and I omitted the last part if this quote on purpose) - I have to disagree. SQL Server performance is almost always I/O bound; the CPU spends enormous amounts of time waiting for the next data to be available. Since a computed column is not stored, it takes less disk space, reducing I/O. Here is a very unlogical and exaggerated example:
CREATE TABLE Demo (KeyCol int NOT NULL PRIMARY KEY, SmallString varchar(10) NOT NULL, Repetitions smallint NOT NULL, LongString AS REPLICATE(SmallString, Repetitions)); If the LongString column is computed and not persisted, rows take approximately 20-30 bytes (I don't have the exact numbers, as I'm on holiday); a single data page (8K) will store approximately 300 rows. The 100,000 rows you mention will be on less than 350 data pages. However, if LongString is a persisted computed column or a regular column, then the amount of bytes per row depends on the length of SmallString and the value of Repetitions. If we assume an average length of 5 bytes for SmallString and an average value of 200 Repetitions, the average length of LongString will be 1,000 bytes; the average row length then is 1,020-1,030 bytes, so we can squeeze only 7 or 8 rows in a data page. The same 100,000 rows now take over 13,000 data pages! This will take much longer for SQL Server to read and process.
The last part of your post, the part I previously omitted from my quote, is "specially if the computed column comes from other tables via UDFs...". This is indeed true. SQL Server can't optimize this very well; it will execute the UDF 100,000 times, so if the UDF has to read from another table, that read will be repeated 100,000 times. Extremely bad for performance. This is but one of the many reasons why using a UDF in a computed column is not recommended.
Hugo Kornelis, SQL Server MVP Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
|
|
|
|