CODEWITHSUNDEEP
sqlsql-server-2008foreign-key-relationship
Abbas
Abbas

Reputation: 5044

Foreign key in SQL Server

I want to know the use of foreign key in SQL Server as I had a debate with one of my colleagues.

I have the opinion, when two tables are connected via a foreign key, when the records are deleted from the parent table then the same reference record from the child table should also get deleted.

Say for example I have two tables, Table1 and Table2. Table1 has one record with id = 1 and Table2 has two records with id = 1. Table2 is a child table and connected with Table1 via a foreign key. Now when I try to delete the id = 1 record from Table1 then id = 1 (2 records) should be deleted from Table2 at the same time.

He says that's wrong. In case of a foreign key, I have to separately delete records from both the tables.

Who is correct?

Upvotes: 3

Views: 824

Answers (6)

SQLMenace
SQLMenace

Reputation: 135011

You are both right.

If cascade delete is enabled then the foreign key rows will also be deleted when the primary key row is deleted.

Upvotes: 1

painotpi
painotpi

Reputation: 6996

It depends on if you have an ON DELETE CASCADE or an ON DELETE SET NULL on your TABLE 1. If you don't have either or if it's INITIALLY DEFERRED then you'll face an INTEGRITY CONSTRAINT, because there will be a child record (in table 2). You can read about it in How does cascade work in cases of delete/update for foreign key?

Upvotes: 1

Ernesto
Ernesto

Reputation: 1592

You can have the tables created to delete in Cascade. When you add the foreign key constraint you need to specify the contraint 

CONSTRAINT fk1
FOREIGN KEY(col) REFERENCES parent(col) ON DELETE CASCADE,

Otherwise, yes, you have to delete children first.

Upvotes: 1

marc_s
marc_s

Reputation: 754488

Both answers can be used and can work.

Your colleague's version puts more responsability on your application (or your DBA) doing the deletion: the app (or DBA) will have to check for child rows first and delete them, and then delete the parent row. This works, and doesn't give you any unexpected surprises.

If you put a ON DELETE CASCADE option on your foreign key constraint (which should be possible in just about any serious relational database system), then the behavior would be the way you describe it - that might make sense, from a business point of view (e.g. delete all order items for an order), but in other cases, it might totally make no sense at all (e.g. if you delete an order no. 1234, you typically don't want to delete all the products the order items for that order will probably reference).

So there are two scenarios - both make sense in certain scenarios, and not such much in others. It's not a simple "either - or" / "right vs. wrong" question at all.

Upvotes: 4

NKCSS
NKCSS

Reputation: 2746

It depends on how things are defined. You can either have a cascading delete, or having it blocked (where you have to delete first the one, then the other)

Upvotes: 1

roberttdev
roberttdev

Reputation: 46523

I believe your friend is right -- referenced tables are not automatically deleted just because you delete a table that has a foreign key. You can set up triggers that will do that, however.

Foreign keys are mainly used to indicate relationships in a data model -- and they can also enforce data integrity between tables by adding extra stuff so that errors are thrown if data is entered without a corresponding key value existing in a reference table.

Upvotes: -2

Related Questions