views:

38

answers:

3

I have the following trigger:

CREATE TRIGGER Users_Delete
   ON  Users 
   AFTER DELETE
AS 
BEGIN

    SET NOCOUNT ON;

    -- Patients
    UPDATE Patients SET ModifiedByID=NULL WHERE ModifiedByID=ID;
    UPDATE Patients SET CreatedByID=NULL WHERE CreatedByID=ID;
    UPDATE Patients SET DeletedByID=NULL WHERE DeletedByID=ID;

END

I was wondering if there's a way to "combine" those three UPDATE statements into something that would be like the following:

UPDATE Patients SET 
(ModifiedByID=NULL WHERE ModifiedByID=ID) OR 
(CreatedByID=NULL WHERE CreatedByID=ID) OR 
(DeletedByID=NULL WHERE DeletedByID=ID);

I'd really like to have only one statement to increase performance.

The reason I'm using the trigger instead on ON DELETE for the FOREIGN KEY is because I'm getting the error that having more than one ON DELETE causes the following error:

Introducing FOREIGN KEY constraint 'FK_Patients_Users_Deleted' on table 'Patients' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.

EDIT: would it be good to have indexes on all of the ModifiedByID, CreatedByID, DeletedByID columns? Deleting a User will of course be rare, so is it worth adding indexes to 3 columns?

+1  A: 

Something like this?

UPDATE Patients SET 
ModifiedByID = CASE WHEN ModifiedByID=ID THEN Null ELSE ModifiedById END,
CreatedByID = CASE WHEN CreatedByID=ID THEN Null ELSE CreatedById END,
DeletedByID = CASE WHEN DeletedByID=ID THEN Null ELSE DeletedById END
WHERE (ModifiedByID = ID OR CreatedByID = ID OR DeletedByID = ID)
Yellowfog
I guess that the only case in which you'd see a performance increase is if the Patients table is very large and you don't have proper indexes on ModifiedByID, CreatedByID, or DeletedByID. In which case the solution is to add the indexes
Yellowfog
So do you think it's just best to use the 3 statements as is with indexes on ModifiedByID/CreatedByID/DeletedByID?
TheCloudlessSky
I strongly suspect that it will make little to no difference, so I'd go with the one that's easier to understand (ie. the three statements)
Yellowfog
Ok, I'll go with that. Do you think it's important to have the indexes on the 3 columns? Isn't it expensive updating indexes?
TheCloudlessSky
General rule of thumb: take a hit when you write data so that you can speed up reading data. Optimizing SQL is fun because you can improve reads by orders of magnitude. Incidentally, I would take note of the comment by HLGEM about why you're doing this at all (when you could be doing soft-deletes), and Martin Smith's point about multiple deletes, which is easy to overlook.
Yellowfog
+1  A: 

You can do it in one statement, but that's not necessarily better for performance.

UPDATE
    Patients
SET
    ModifiedByID = CASE WHEN ModifiedID = ID THEN NULL ELSE ModifiedID,
    CreatedByID = CASE WHEN CreatedByID = ID THEN NULL ELSE CreatedByID,
    DeletedByID = CASE WHEN DeletedByID = ID THEN NULL ELSE DeletedByID

I really doubt that this will perform better though.

Tom H.
+2  A: 

Regarding your original question.

Not really. I can't come up with anything better than

UPDATE Patients 
SET ModifiedByID= CASE WHEN ModifiedByID=ID THEN NULL ELSE ModifiedByID END,
CreatedByID= CASE WHEN CreatedByID=ID THEN NULL ELSE CreatedByID END,
DeletedByID= CASE WHEN DeletedByID=ID THEN NULL ELSE DeletedByID END
WHERE
ModifiedByID  IN (SELECT ID FROM DELETED)
OR 
CreatedByID  IN (SELECT ID FROM DELETED)
OR
DeletedByID  IN (SELECT ID FROM DELETED)

Note that this handles a multi row delete correctly. It is unclear from what you posted whether your current trigger does.

Martin Smith
Important point, many people code against a single record and fail as a result in multi-row actions.
Nissan Fan