删除记录时如何检查外键约束是否失败

Question

I have created a database in SQL Server and front end is PHP - CodeIgniter. In the database I have created multiple foreign keys with other tables. Now when the user tries to delete the record, instead of really deleting I want to flag the record as deleted = 1 , this should only be done when there will be no reference records are available in child table. Below are example tables:

Parent_Table
Id INT(PK), Name Varchar, deleted INT

Child_Table
Id INT(PK), FK_Parent_Table_ID INT, address varchar, deleted INT

Above is just example of my tables. Now whenever a user tries to delete a record from the parent table foreign key will check for constraint and then delete the record, here instead of actual deletion I want it flag as deleted = 1 .

I have tried using transaction->start and transaction->complete so if foreign key fails the transaction gets aborted but here the problem is if the foreign key not failing then the rollback will occur and in that case the PRIMARY KEY of the record will be changed that should not be done.

So, I want a way to check the foreign key conflict before transaction starts without actual deletion of the record

Answer 1

To implement what you are asking, just check for the existence of a record in the child table eg

declare @RecordToDelete int = 123;

-- Delete the record if no child records exist
delete
from Parent_Table
where id = @RecordToDelete
and not exists (select 1 from Child_Table where FK_Parent_Table_ID = @RecordToDelete);

-- Flag the record as deleted if child records exist
update Parent_Table set
    Deleted = 1
where id = @RecordToDelete
and exists (select 1 from Child_Table where FK_Parent_Table_ID = @RecordToDelete);

Depending on whether you really need to keep the record, because you could always create your foreign keys with a cascade delete.

With 15+ child tables I would seriously consider just always flagging the record as deleted and never bothering to actually delete those without child records. A few extra records is unlikely to make much difference to your database.

---

Actually in my experience child tables fall into 2 categories:

• Those that can automatically be deleted using a cascade delete
• Those that should prevent us from deleting the parent record

If this is the case the checks required should become more manageable.

---

Also for these situations I recommend encapsulating the delete logic within a stored procedure in order to keep it all in one place, and be easy to modify if the database schemes changes in future.

---

Note: Personally I would make the Deleted column a bit rather than an int as it more accurately reflects the intention.