Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345»»

Effective Dating Series Part I - The Problem Expand / Collapse
Author
Message
Posted Thursday, October 1, 2009 11:58 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 11:56 AM
Points: 880, Visits: 2,435
Jason Whitney (10/1/2009)
I have run into this before, and the article gives the first half of the solution. The second part is what I can't figure out; how to avoid overlapping time-frames.

The supplied solution doesn't enforce data integrity for overlapping dates. For the illustration given it may not need to, but for many applications these date ranges must be mutually exclusive. For example a patient comes in to the hospital as an outpatient (O) and has a complication and gets admitted as an inpatient (I). The data is temporal, but the dates/times cannot overlap. How would I model this?

The only solution I have been able to come up with is a new data type for interval data. (Hopefully we will see this in the next version of SQL) I tried a CLR, but I was never able to get it to work quite right. My database has failed me!


Yes, that's what I was talking about, and that is the serious problem with trying to represent an interval within a row in SQL Server.

You can do a function based check constraint that applies one of the available overlap detections, such as the simple (and SQL Server 2000 friendly). As mentioned, it's expensive. There may be better solutions for 2000, and I think there are for 2005, but I don't know them.

Essentially:
CROSS JOIN the table to itself (call them Outer and Inner)
WHERE Inner.UniqueRowKey <> Outer.UniqueRowKey (one row doesn't overlap with itself)
AND Inner.KeyThatShouldNotOverlap = Outer.KeyThatShouldNotOverlap (so we only look at row sets that, in combination, can overlap when they shouldn't)
AND Inner.effdate <= Outer.termdate (one starts before/equal to when the other ends)
AND Inner.termdate >= Outer.effdate (and that one also ends after/equal to when the other starts)

Add in as many fields in composite keys as you need.

If you don't have a truly unique row identifier... add one to the table, build one, concatenate fields to get one, or do some AND/OR within nested parenthesis as appropriate.

Post #796530
Posted Thursday, October 1, 2009 2:04 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, October 20, 2014 11:55 AM
Points: 1,330, Visits: 19,306
Why would you want the db to do this? Why wouldn't you require the application to term the existing record with the timestamp when the change occurred -1 (millisecond, second, whatever) and start a new record with the timestamp when the change occurred to whatever the termdate is? Then the user just hits a button or whatever and the app takes care of the rest.



---------------------------------------------------------
How best to post your question
How to post performance problems
Tally Table:What it is and how it replaces a loop

"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Post #796615
Posted Thursday, October 1, 2009 2:19 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 11:56 AM
Points: 880, Visits: 2,435
jcrawf02 (10/1/2009)
Why would you want the db to do this? Why wouldn't you require the application to..[clipped]..the app takes care of the rest.


Philosophically, with this argument, why do you want the DB to have _any_ constraints at all?

Because I assume there are multiple apps, at least one is flawed, and at least some rows will sooner or later be entered another way.
Post #796630
Posted Thursday, October 1, 2009 2:27 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, October 20, 2014 11:55 AM
Points: 1,330, Visits: 19,306
Nadrek (10/1/2009)
jcrawf02 (10/1/2009)
Why would you want the db to do this? Why wouldn't you require the application to..[clipped]..the app takes care of the rest.


Philosophically, with this argument, why do you want the DB to have _any_ constraints at all?

Because I assume there are multiple apps, at least one is flawed, and at least some rows will sooner or later be entered another way.

Hardly saying that, but you're arguing that the db needs to be perfect where the app is not, versus the reverse. Since the goal of the app should be to reduce the work the user has to perform to accomplish the task, it should already be doing this.


---------------------------------------------------------
How best to post your question
How to post performance problems
Tally Table:What it is and how it replaces a loop

"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Post #796633
Posted Thursday, October 1, 2009 2:41 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 2:01 PM
Points: 38, Visits: 538
jcrawf02 (10/1/2009)
Nadrek (10/1/2009)
jcrawf02 (10/1/2009)
Why would you want the db to do this? Why wouldn't you require the application to..[clipped]..the app takes care of the rest.


Philosophically, with this argument, why do you want the DB to have _any_ constraints at all?

Because I assume there are multiple apps, at least one is flawed, and at least some rows will sooner or later be entered another way.

Hardly saying that, but you're arguing that the db needs to be perfect where the app is not, versus the reverse. Since the goal of the app should be to reduce the work the user has to perform to accomplish the task, it should already be doing this.


I'm a DBA, so yes, the db must be perfect. Also we may have multiple applications accessing a single database so I don't want to rely on the application logic. Also, the application should reduce the work a user has to perform, but this is completely different from accurately modeling the data. Part of data modeling in this case is the ability to store interval or ranged data (dates or numbers) that do not overlap.
Post #796641
Posted Thursday, October 1, 2009 2:59 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, October 10, 2014 3:19 PM
Points: 28, Visits: 185
As a developer, the best practice here in my opinion, is to wrap all data update/inserts/deletes for those table into a stored procedure with the validation logic. All apps would have no ability to update that data without calling the stored procedure to proxy the work. I know this may not help for existing legacy apps where source code isn't available and recompiling (if it's a compiled app) isn't possible, but the more business rules that can go on the server and not on the client, the better we are.
--Jim
Post #796646
Posted Thursday, October 1, 2009 3:18 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, October 22, 2014 8:26 AM
Points: 147, Visits: 544
James Stephens (10/1/2009)
As a developer, the best practice here in my opinion, is to wrap all data update/inserts/deletes for those table into a stored procedure with the validation logic. All apps would have no ability to update that data without calling the stored procedure to proxy the work. I know this may not help for existing legacy apps where source code isn't available and recompiling (if it's a compiled app) isn't possible, but the more business rules that can go on the server and not on the client, the better we are.
--Jim


That's a great approach to strive for, but unless insert, update, and delete are revoked on the table, somebody might still connect outside of your application and enter data directly into it that violates business rules. Also, this approach does not eliminate any overhead, it just moves it to a different place.

On the bright side, if the rules are enforced from insert/update triggers, the entire table does not need to cross join to itself, it just needs to cross join with the "inserted" temp table that is provided to the trigger by the database engine. Hopefully only a small number of rows (if more than one) will ever be inserted/updated at a time during normal production activity.



Post #796660
Posted Thursday, October 1, 2009 5:48 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, October 22, 2014 9:33 PM
Points: 3, Visits: 120
This will make my job obsolete as a BI person but ...
Add an identity column (surrogate key), and a Change_Type (price change, promo etc) to the renamed Prod_Hist (was called Promo_Prod) along with the natural keys (only really need the from date as these must be continuous from and to dates - more than one promo active does not make sense to me - sounds like a larger thing than product - we call it a bundle in telco - thats another discussion).
Use the TSQL Merge Statement as follows ...
For new (inserted) products you create a new Promo_Prod with no to date or largest date possible for the data type (means no expiry) and the current price. For changes to product price use merge to update old price's to date and insert new price from date with same to date and null for the to date. Same for promos changes. When orders are created they use the price in the Prod-Hist since it only exists there. There's a lot more to this for complex requirements but this is a good taste for a simple requirement around price and promo changes.

excuse my quick answer for spelling, clarity etc.
Post #796697
Posted Friday, October 2, 2009 3:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, October 17, 2014 3:41 AM
Points: 210, Visits: 116
Jason Whitney (10/1/2009)
jcrawf02 (10/1/2009)
[quote]Nadrek (10/1/2009)
[quote]jcrawf02 (10/1/2009)
Why would you want the db to do this? Why wouldn't you require the application to..[clipped]..the app takes care of the rest.


I'm a DBA, so yes, the db must be perfect. Also we may have multiple applications accessing a single database so I don't want to rely on the application logic.


That's what stored procedures are for.



Post #796800
Posted Friday, October 2, 2009 4:37 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, April 17, 2014 3:29 AM
Points: 229, Visits: 421
Quite - as the DBA you should be revoking all privileges on all tables and only allowing pre designed updates via stored procedures - that's the only way you can guarantee data integrity. Are your developers DBAs? No. So why give them the opportunity to compromise your data? Yeah, yeah, rapid response yadda yadda, flexibility yadda yadda, all means nothing when your data is compromised.

Post #796811
« Prev Topic | Next Topic »

Add to briefcase «««12345»»

Permissions Expand / Collapse