|
|
|
SSCertifiable
       
Group: Moderators
Last Login: Tuesday, June 11, 2013 6:34 AM
Points: 6,463,
Visits: 1,388
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 1:35 AM
Points: 139,
Visits: 4,605
|
|
I like your articles because are very didactic and thinking in a lot of ways how to do it.
This one with so many "steps" (approximations), has been useful for me to learn that exists the 'PERSISTED' keyword.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, April 11, 2013 12:58 AM
Points: 174,
Visits: 555
|
|
It blows me out...I have held off computed columns for the longest time as I thought they would be a performance hit.
Theoretical questions:
1. Would it be faster when using numbers than characters? 2. Will it accept db standard functions e.g. cast/convert, ltrim, rtrim? 2.1 corollary, will it accept user-defined functions?
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, May 31, 2013 8:22 AM
Points: 2,
Visits: 29
|
|
We used computed columns for an interesting purpose back in SQL 2000. Then it stopped working in 2005. We posted about it on a couple of forums (including MS Technet) - never got a resolution.
I've cobbled this post together from those places.
Here is a script of the CREATE
CREATE TABLE [SchoolPeriod_T] ( [Yr] [int] NOT NULL , [Bldg] [tinyint] NOT NULL , [PerDay] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [PerSlot] [tinyint] NOT NULL , [PerStart] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [PerEnd] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [Period] [varchar] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [PerType] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [DayOrder] AS (case (left([PerDay],1)) when 'M' then '1' when 'T' then '2' when 'W' then '3' when 'R' then '4' when 'F' then '5' else '0' end) , CONSTRAINT [PKSchoolPeriod] PRIMARY KEY CLUSTERED ( [Yr], [Bldg], [DayOrder], [PerDay], [PerSlot] ) ON [PRIMARY] , CONSTRAINT [FKSchoolPeriodSchoolYr] FOREIGN KEY ( [Bldg], [Yr] ) REFERENCES [SchoolYr_T] ( [Bldg], [Yr] ) ) ON [PRIMARY] GO The DAYORDER was made part of the CLUSTERED PK.
This worked until SQL 2005
Now in a SPROC we had this did not work anymore
. . . Set ArithAbort On Set CONCAT_NULL_YIELDS_NULL On Set QUOTED_IDENTIFIER On Set ANSI_NULLS On Set ANSI_PADDING On Set ANSI_WARNINGS On Set NUMERIC_ROUNDABORT Off . . . If @Copy_School_Period$N_Y='Y' Begin insert into schoolperiod_t (Yr, Bldg, PerDay, PerSlot, PerStart, PerEnd, Period, PerType) SELECT @Current_Yr+1, Bldg, PerDay, PerSlot, PerStart, PerEnd, Period, PerType FROM Stufiles.dbo.SchoolPeriod_T Where Yr=@Current_Yr and Bldg=@Bldg$$
Getting this error:
INSERT failed because the following SET options have incorrect settings: 'ARITHABORT'.
err # -2147217900
But this same thing works in a query window
Begin Tran insert into schoolperiod_t (Yr, Bldg, PerDay, PerSlot, PerStart, PerEnd, Period, PerType) SELECT 2008, Bldg, PerDay, PerSlot, PerStart, PerEnd, Period, PerType FROM Stufiles.dbo.SchoolPeriod_T Where Yr=2007 and Bldg=10 Rollback And this link talks about the problem...
http://msdn2.microsoft.com/en-gb/library/aa933126(SQL.80).aspx - but apparently I'm making all those settings - any ideas??
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Friday, June 14, 2013 1:38 PM
Points: 1,585,
Visits: 1,002
|
|
One thing that limits the use of persited calculated columns is the many requirements it has, which can be a headache for legacy systems.
The main issue for legacy code is that all procedures etc that insert / update / delete from the table / index must have certain set options set to on or off or the insert / update / delete fails. Any select against the column will also not use the index if the set options are incorrect.
There are a few other requirements such as functions used in the calculation having the same owner etc. which you can find in BOL.
They are a very good option, but you may not be able to easily take full advantage of them.
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Friday, June 14, 2013 1:38 PM
Points: 1,585,
Visits: 1,002
|
|
I believe I had to actually create the procedures with the appropriate options before the problem was resolved, and not just set them within the procedure.
SET NUMERIC_ROUNDABORT OFF SET ANSI_NULLS ON SET ANSI_PADDING ON SET ANSI_WARNINGS ON SET ARITHABORT ON SET CONCAT_NULL_YIELDS_NULL ON SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE
.....
GO
|
|
|
|
|
SSCertifiable
       
Group: Moderators
Last Login: Tuesday, June 11, 2013 6:34 AM
Points: 6,463,
Visits: 1,388
|
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, March 06, 2009 7:23 AM
Points: 8,
Visits: 49
|
|
On more complex calc's or those calling functions, computed columns provide a significant hit on performance..I used to use them heavily...I would suggest using them sparingly.
Also, you cannot use alter to modify the calc which is another pain. Modifications to the computed col require a drop and recreate.
My blog: jetlounge.net
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 9:52 PM
Points: 7,002,
Visits: 14,001
|
|
David Leibowitz (2/12/2008) On more complex calc's or those calling functions, computed columns provide a significant hit on performance..I used to use them heavily...I would suggest using them sparingly.
Also, you cannot use alter to modify the calc which is another pain. Modifications to the computed col require a drop and recreate.
do you use IsPersisted in those cases? Because I've seen very LITTLE performance hits once you mark them as persisted. Of course - if the calculation drags down your insert and update performance, that wouldn't be good either.
---------------------------------------------------------------------------------- Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, March 06, 2009 7:23 AM
Points: 8,
Visits: 49
|
|
not all calc's can be persisted... especially those that call functions.
in reality, i see no difference between a persisted computed column and an update trigger that sets a value on a column to a static value. the real value of computed columns is the runtime evaluation of an algorithm..unfortunately, there is a big performance hit...as expected i suppose. this isn't magic.
My blog: jetlounge.net
|
|
|
|