<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Joshua Go - Latest Comments in Foreign key cascade on update dangerous?</title><link>http://joshuago.disqus.com/</link><description></description><atom:link href="https://joshuago.disqus.com/foreign_key_cascade_on_update_dangerous/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Fri, 06 May 2011 10:56:47 -0000</lastBuildDate><item><title>Re: Foreign key cascade on update dangerous?</title><link>http://joshua-go.blogspot.com/2008/07/foreign-key-cascade-on-update-dangerous.html#comment-198355728</link><description>&lt;p&gt;My personal feeling is that if you have non-unique values in a parent table, then you probably have more of a poor database design issue which should be addressed by going through some normalization exercises.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Troy</dc:creator><pubDate>Fri, 06 May 2011 10:56:47 -0000</pubDate></item><item><title>Re: Foreign key cascade on update dangerous?</title><link>http://joshua-go.blogspot.com/2008/07/foreign-key-cascade-on-update-dangerous.html#comment-192295647</link><description>&lt;p&gt;It is a question as the post name indicates and my guess is we will find responses here attempting to answer the question.&lt;/p&gt;&lt;p&gt;My guess is that this would be bad if the parent table allows non unique values and the child table relies on a unique values but not so easily recognizable at table design. &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous Coward</dc:creator><pubDate>Tue, 26 Apr 2011 18:28:04 -0000</pubDate></item><item><title>Re: Foreign key cascade on update dangerous?</title><link>http://joshua-go.blogspot.com/2008/07/foreign-key-cascade-on-update-dangerous.html#comment-64990736</link><description>&lt;p&gt;I didn't realize I left this so open-ended. Nobody could quite answer it definitively, so I'll have to rely on the two years of experience and use cases since then.&lt;/p&gt;&lt;p&gt;I've come to the conclusion that it's OK to use cascade on update, but you should be careful when doing cascade on delete.&lt;/p&gt;&lt;p&gt;The reasoning behind this is that cascade on update only updates foreign keys so that other things pointing to the updated rows maintain referential integrity. But then again, you shouldn't have to update primary keys very often, so just stay off.&lt;/p&gt;&lt;p&gt;Cascade on delete is more dangerous, but you may want to do it to save yourself trouble. I'd personally not have trouble with putting a "CASCADE ON DELETE" on a table -- but only if all the other rows pointing to a row on that table were useless without it. If those table rows with foreign keys into your "CASCADE ON DELETE"-enabled table can exist independently, don't enable "CASCADE ON DELETE" to protect yourself against accidental deletions.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Joshua Go</dc:creator><pubDate>Wed, 28 Jul 2010 20:56:26 -0000</pubDate></item><item><title>Re: Foreign key cascade on update dangerous?</title><link>http://joshua-go.blogspot.com/2008/07/foreign-key-cascade-on-update-dangerous.html#comment-64621838</link><description>&lt;p&gt;give us some more info on this topic. I am looking into foreign keys and how to best use them in differen situatutions. This short blog is more a question than an answer. let us know if you find out the answer&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">MMA Mail Magazine</dc:creator><pubDate>Tue, 27 Jul 2010 09:24:22 -0000</pubDate></item></channel></rss>