views:

61

answers:

2

Rules (Transact-SQL)[1] are reusable what permitted to overcome the shortcoming of non-re-usability of check constraints.

And now I read [1] that:

  • "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. We recommend that you use check constraints instead. Check constraints are created by using the CHECK keyword of CREATE TABLE or ALTER TABLE"

So, what is instead of rules and why are they deprecated?


==== Update:
AlexKuznetsov, are table-level check constraints terribly slow?
Or, table-level check constraints using functions are slow in comparison with column-level check constraints and resp. rules as their equivalents (since rules are only column-level)?

In other words, are column-level check constraints and rules (implicitly being only column-level) are equal in performance?
Then, I see only removal of re-usability feature. The use of non-reusable table-level constraints were present before.

Also, I am more interested in knowing why and what to further expect then to know how to implement custom substitutes for deprecated system features using old features which had always been available before.

[1]
MS SQL Server 2008 R2 Books On Line. CREATE RULE (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms188064.aspx

+1  A: 

Well one reason rules are probably taking the sideline is I believe with rules you can only have one per a column and they only check data going into the database, that is they don't check existing data already in the database. With check constraints you can have multiple constraints on a given column and they enforce on all data(data coming in and data already in the database). Given that rules seem to be a poor man solution to what check constraints are Microsoft probably finally realized it was time to get rid of them, plus they aren't SQL standard.

If a check constraint doesn't cut it you can also look at using a trigger for more elaborate logic.

StarShip3000
+2  A: 

If you're concern is you want to write the "code" to constrain once and re-use it on multiple columns, I suggest you do the following:

Create a function with your constraint rules:

CREATE FUNCTION schema.PositiveInteger(INT val)
RETURNS INT AS
BEGIN
    IF (val > 0) RETURN 1
    ELSE RETURN 0
END

Add that function as a constraint to the column:

ALTER TABLE tbl ADD CONSTRAINT chkMyRules CHECK (schema.PositiveInteger(tbl.IntColumn) = 1);

The best part about this is, you can now write re-usable rules that take into account multiple columns.

CREATE FUNCTION ... (INT val, DATETIME date) RETURNS INT AS ......
ALTER TABLE tbl ADD CONSTRAINT chkMultipleCols CHECK (func(col1, col2) = 1);

Enjoy!

Jeff Wight
the not so good part about this is slowness: this approach is terribly slow
AlexKuznetsov
Thanks for the input. Can you source it? Also do you have any idea what the performance of rules are compared to this? I know there are side effects to check constraints (http://tinyurl.com/2bc2xoe) (and I notice you've seen that page before), but I have to imagine those side effects are present in Rules as well. As a replacement for rules, I think this would work rather well.
Jeff Wight
Jeff, I upvoted your answer as helpful but it is somewhat orthogonal to my question context of introduction of "modern" (new) changes, policies, trends.
vgv8