469,275 Members | 1,629 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,275 developers. It's quick & easy.

Any possibility of creating a MUTUALLY dependent CHECK

Hi,

DDL:
-- create table #task (taskID int identity(1,1) primary key, taskName
varchar(25) unique, taskCompleteDate dateTime, taskComplete bit
default(0));
/*
Business Rules:
a) if taskCompleteDate is NULL (like default) then, taskComplete may
not be set to 1 (attempt to update it to 1 would fail);
b) else automatically set taskComplete = 1
*/
I was thinking using CHECK constraint (mutual constraint if possible),
along the following line:
CHECK (if taskCompleteDate is null set taskComplete=0 else set
taskComplete=1)

Hmm, your thought?
Thanks.
Jul 20 '05 #1
5 2671
Why not just eliminate the transitive dependency? The taskcomplete column is
redundant unless you wanted to allow a case where taskcomplete = 1 but the
date is NULL (you know the task is complete but the date is unknown). Since
your business rule excludes that case I would just put the taskcomplete
column in a view:

CREATE SomeView AS
SELECT ... taskcompletedate, CASE WHEN taskcompletedate IS NULL
THEN 1 ELSE 0 END, ...

Also, why so many nullable columns? Aparently you don't have a natural
primary key (should it be Taskname?).

In answer to your question, yes you can create a mutually dependent
constraint, but the purpose of a constraint is to validate data not to
change it:

.... taskcompletedate DATETIME, taskcomplete BIT NOT NULL DEFAULT 0, CHECK
((taskcompletedate IS NULL AND taskcomplete=0) OR (taskcompletedate IS NOT
NULL AND taskcomplete=1))...

--
David Portas
------------
Please reply only to the newsgroup
--
Jul 20 '05 #2
qw********@boxfrog.com (Doug Baroter) wrote in message news:<fc**************************@posting.google. com>...
Hi,

DDL:
-- create table #task (taskID int identity(1,1) primary key, taskName
varchar(25) unique, taskCompleteDate dateTime, taskComplete bit
default(0));
/*
Business Rules:
a) if taskCompleteDate is NULL (like default) then, taskComplete may
not be set to 1 (attempt to update it to 1 would fail);
b) else automatically set taskComplete = 1
*/
I was thinking using CHECK constraint (mutual constraint if possible),
along the following line:
CHECK (if taskCompleteDate is null set taskComplete=0 else set
taskComplete=1)

Hmm, your thought?
Thanks.

You could implement the CHECK constraint like this:

create table #task (
taskID int identity(1,1) primary key,
taskName varchar(25) unique,
taskCompleteDate dateTime,
taskComplete bit default(0),
constraint CHK_taskComplete check ((taskCompleteDate is null and
taskComplete = 0) or (taskCompleteDate is not null and taskComplete =
1))
);

Or use a computed column:

create table #task (
taskID int identity(1,1) primary key,
taskName varchar(25) unique,
taskCompleteDate dateTime,
taskComplete as case when taskCompleteDate is not null then 1 else 0
end
);

The taskComplete flag seems to be redundant, given that you can use
taskCompleteDate for the same purpose, but presumably there's a reason
for this in your environment.

Simon
Jul 20 '05 #3
Thanks. I was losing the link between "check" and "contraint" :)

sq*@hayes.ch (Simon Hayes) wrote in message news:<60**************************@posting.google. com>...
qw********@boxfrog.com (Doug Baroter) wrote in message news:<fc**************************@posting.google. com>...
Hi,

DDL:
-- create table #task (taskID int identity(1,1) primary key, taskName
varchar(25) unique, taskCompleteDate dateTime, taskComplete bit
default(0));
/*
Business Rules:
a) if taskCompleteDate is NULL (like default) then, taskComplete may
not be set to 1 (attempt to update it to 1 would fail);
b) else automatically set taskComplete = 1
*/
I was thinking using CHECK constraint (mutual constraint if possible),
along the following line:
CHECK (if taskCompleteDate is null set taskComplete=0 else set
taskComplete=1)

Hmm, your thought?
Thanks.

You could implement the CHECK constraint like this:

create table #task (
taskID int identity(1,1) primary key,
taskName varchar(25) unique,
taskCompleteDate dateTime,
taskComplete bit default(0),
constraint CHK_taskComplete check ((taskCompleteDate is null and
taskComplete = 0) or (taskCompleteDate is not null and taskComplete =
1))
);

Or use a computed column:

create table #task (
taskID int identity(1,1) primary key,
taskName varchar(25) unique,
taskCompleteDate dateTime,
taskComplete as case when taskCompleteDate is not null then 1 else 0
end
);

The taskComplete flag seems to be redundant, given that you can use
taskCompleteDate for the same purpose, but presumably there's a reason
for this in your environment.

Simon

Jul 20 '05 #4
"why so many nullable columns?" you're right.
It's not an actual table, just to get a point across for the question. Thanks.

"David Portas" <RE****************************@acm.org> wrote in message news:<Gf********************@giganews.com>...
Why not just eliminate the transitive dependency? The taskcomplete column is
redundant unless you wanted to allow a case where taskcomplete = 1 but the
date is NULL (you know the task is complete but the date is unknown). Since
your business rule excludes that case I would just put the taskcomplete
column in a view:

CREATE SomeView AS
SELECT ... taskcompletedate, CASE WHEN taskcompletedate IS NULL
THEN 1 ELSE 0 END, ...

Also, why so many nullable columns? Aparently you don't have a natural
primary key (should it be Taskname?).

In answer to your question, yes you can create a mutually dependent
constraint, but the purpose of a constraint is to validate data not to
change it:

... taskcompletedate DATETIME, taskcomplete BIT NOT NULL DEFAULT 0, CHECK
((taskcompletedate IS NULL AND taskcomplete=0) OR (taskcompletedate IS NOT
NULL AND taskcomplete=1))...

Jul 20 '05 #5
Oops, I did a slightly different implementation on an existing table,
so, I created a check constraint via EM, the contraint reads:
([JobEndDate] is null and [JobComplete] = 0 OR [JobEndDate] is not
null and [JobComplete] = 1)

/*
consider job in place of task, thanks;
I thought with the check constraint, if JobEndDate is updated with a
value then JobComplete column would be automatically updated with
value of 1, didn't seem to work this way
*/

Attempt to update JobEndDate failed due to the constraint, err msg:
UPDATE statement conflicted with TABLE CHECK constraint
'CK_JobDateStatus'

Appreciated.
You could implement the CHECK constraint like this:

create table #task (
taskID int identity(1,1) primary key,
taskName varchar(25) unique,
taskCompleteDate dateTime,
taskComplete bit default(0),
constraint CHK_taskComplete check ((taskCompleteDate is null and
taskComplete = 0) or (taskCompleteDate is not null and taskComplete =
1))
);

Jul 20 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Brad Kartchner | last post: by
14 posts views Thread by G Patel | last post: by
3 posts views Thread by vipin | last post: by
2 posts views Thread by mscertified | last post: by
8 posts views Thread by arun | last post: by
2 posts views Thread by arun | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.