I would like to know when to actually use cascade, when to use or remove restrictions or update cascade or restrict I I am quite confused in using them or applying in my database.
Using cascading operators on foreign key constraints is a bit of a hot topic.
In theory, if you know for a fact that the removal of an original item will automatically mean removing all the children's objects, then the link between the child and the parent table may have meaning is. Imagine a "machine" that contains "parts" If your logic tells you that the machine is destroyed, then all the parts that are made of that machine have to be cleaned from the database, You can use a cascade detection option on the foreign key link between the parts table and the machine table. / P>
Though: This can be a bit tricky, especially if you end the whole series of tables related to this option, so developers try to handle it in your data access code rather than defining it in many databases I like it.
The update cascade is usually used when the primary key is changed in an original table - to update all related hair tables and rows to reflect that change, it is usually a database The code is considered odor - the better option here is to ensure that the primary key never changes, so that it does not require cascading updates - eg By presenting an artificial "surrogate" key column in your table, which has no business-related meaning and thus it is never updated.
Does this help everything? Any special details you are still not ambiguous?
My take is this: While it is a great idea in theory, most developers do not really use it in "real live" - most developers will select it, handle it in data access codes, which Gives complete and explicit control over the deletion (or updates).
Comments
Post a Comment