Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Computed Columns


Computed Columns

Author
Message
JohnG69
JohnG69
SSChasing Mays
SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)SSChasing Mays (601 reputation)

Group: General Forum Members
Points: 601 Visits: 452
Comments posted to this topic are about the item Computed Columns
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2420 Visits: 2204
This is a nice question but I have to disagree with your answer. Actually just one part of it: "Will definitely use more resources." which I can't believe is true. I looked at your links and I didn't see anything that stated that they will always use more resources. With that statement it means that there can never be a case where they use less resources, which I can come up with an example where they would. If you had said they will use more CPU resources, maybe, but not always... In this case I think it is like Paul Randal says: "It depends!"

* Right off the bat a non-persisted computed column uses less storage space/time than a persisted computed column.
* If a column can be calculated from other columns in the table, but is rarely used by not actually storing it you could save the CPU of calculating it, the I/O and space of storing it, as well as the I/O of reading it each time the record it relates to is read.
* If you have very slow storage it might be faster to have the CPU calculate it every time it is used instead of storing and reading it.
* I'm not sure but I assume since it is calculated on use it wouldn't be stored in the buffer pool, so non-persisted computed columns probably use less RAM.
sqljohn (twitter)
sqljohn (twitter)
SSC-Enthusiastic
SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)

Group: General Forum Members
Points: 161 Visits: 76
i agree on the '"Will definitely use more resources." being a dodgy part of the question.

which resources are we talking about? it will most likely save developer resources as the calc is done once, probably save maintenance resources as its easy to fix.

if the calculation is a+b will that use more resources that including a+b in a view?
hrvoje.piasevoli
hrvoje.piasevoli
Old Hand
Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)

Group: General Forum Members
Points: 379 Visits: 510
Now this doesn't hold true:
Will definately use more resources.

I am very pleased that UMG developer made a thorough explanation in the previous comment as it was exactly my thought but I couldn't had written it on my phone.
And to add some value to it I think other than being more precise with the resources option you could have thrown in an option relating to indexes or inserts (w/ or wo/ instead of triggers), language dependent functions...
I myself have written a calendar table w/ one physical date column, one computed persisted integer column and a whole bunch of non-persisted columns calculated from the date column.
It

Hrvoje Piasevoli
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2420 Visits: 2204
The other thing that comes to mind is that is an incomplete statement. It doesn't say what it will use more resources than.

* Using a persisted computed column instead: It depends.
* Calculating in a view instead: probably not.
* Calculating in an SP instead: probably not.
* Calculating in the client app instead: probably not. (It may even use less as the client may only need the computed column so there would be less network traffic if the computed column was smaller than the components that make it up.)

What else could it be compared to?
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2420 Visits: 2204
hrvoje.piasevoli (7/21/2010)
I myself have written a calendar table w/ one physical date column, one computed persisted integer column and a whole bunch of non-persisted columns calculated from the date column.
It


I'm curious did you test and find that using non-persisted columns was faster than pre-calculating and storing all the permutations that you needed? (I guess it would probably depend on the storage system speed and a number of other variables.)
hrvoje.piasevoli
hrvoje.piasevoli
Old Hand
Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)

Group: General Forum Members
Points: 379 Visits: 510
...And off it goes posted unfinished (sorry about that).
I think it might be a good idea to have a peer-review of ones Q and A before submitting a QoD to avoid frustration we've all whitnessed when people encounter inprecise or ambiguous answers.
I personaly don't mind having some points not awarded, but find that questionable QoDs yield more contention in quality of the discussion that follows.

Regards,
Hrvoje

Hrvoje Piasevoli
hrvoje.piasevoli
hrvoje.piasevoli
Old Hand
Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)Old Hand (379 reputation)

Group: General Forum Members
Points: 379 Visits: 510
I'm curious did you test and find that using non-persisted columns was faster than pre-calculating and storing all the permutations that you needed? (I guess it would probably depend on the storage system speed and a number of other variables.)

I find the aproach more manageable than using an SP and cleaner from the design point of view. And I can always make some other column persisted by a simple alter statement. (well not realy - has to be deterministic which is not the case with all columns). It is used primarily in warehouse solutions and therefore performance was never really an issue as it is loaded in an SSAS cube and persisted there. It also has a neat effect of being culture and language aware out of the box.

Hrvoje Piasevoli
Duncan Pryde
Duncan Pryde
Hall of Fame
Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)

Group: General Forum Members
Points: 3444 Visits: 1552
A good question, apart from the ambiguity surrounding the resources question. Since it's calculated at runtime, it doesn't use any disk resources, and I can't see how having a select statement along the lines of SELECT a + b AS C, <other_columns> FROM <table> would use less resources than SELECT C, <other_columns> FROM <table> when C is a computed column from a + b.

Obviously, if you're using scalar UDF's in non-persisted computed columns, there's a pretty good chance you'll be hit by performance problems somewhere down the line - as I've just discovered on one of our systems, so perhaps that was it?

Duncan
Stewart "Arturius" Campbell
Stewart "Arturius" Campbell
SSCertifiable
SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)SSCertifiable (6.7K reputation)

Group: General Forum Members
Points: 6650 Visits: 7202
overall a good question, just the bit about resource usage that appears incomplete,

Stating "Will definately use more resources" is the same as asking how long a piece of string is. Lack of equable context renders it vague.

____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search