| Start |
|---|
| ON DELETE CASCADE Assume you have a application that administers rooms. Now, every client has N rooms. This should mean that you have a foreign key on your room table, referencing the client table. Assuming a client moves on to some other software, you'll have to delete his data in your software. But if you do Then you'll get a foreign key violation, because you can't delete the client when he still has rooms. Now you'd have write code in your application that deletes the client's rooms before it deletes the client. Assume further that in the future, many more foreign key dependencies will be added in your database, because your application's functionality expands. Horrible. For every modification in your database, you'll have to adapt your application's code in N places. Possibly you'll have to adapt code in other applications as well (e.g. interfaces to other systems). There is a better solution than doing it in your code. Now you can say and the rooms are automagically deleted when the client is deleted. One word of caution: In Microsoft SQL-Server, this won't work if you have a table that references itselfs. So if you try to define a delete cascade on a recursive tree structure, like this: it won't work, because Microsoft-SQL-server doesn't allow you to set a foreign key with PostgreSQL on the other hand can do this; A word of caution: |
Read Article
https://develop.horje.com/learn/1434/reference