Gustav Brock
gustav at cactus.dk
Sun Feb 2 06:37:01 CST 2003
Hi John >>I guess your intention is to warn the less experienced developer from >>applying RI with cascade-delete set to on. This warning is right - > Correct, that is my intention. Actually the point is that RI is set up by > default with cascade delete off. LEAVE IT (cascade delete) OFF! If you > need to delete things, do it with queries and transactions. > I will admit to turning cascade delete on as an administrator, deleting all > the data for a specific massive set of records in 20 related tables, then > turning cascade delete back off. I could have done it with queries, but I > am the DBA and I know what I am doing. > Using cascade delete as a tool to allow users to delete records is risky. > You may be able to find specific instances where it works without any risks, > but as a rule - "ya shouldn't be doin' that". OK, I think we are narrowing this in now to my initial point - as a comment to Arthur who seems to abandon cascade-delete totally. I know you love your Trash flag to prevent to physically delete records; other use timestamps but the principle is the same. And those records may have valuable child records like order statistics etc. With the lower price on disk space and faster servers and workstations it has become easier to stick to this non-delete principle. In those cases cascade-delete is turned off for those tables. What I am talking about is strictly child records of no value without their parent record. We are now talking about clean-up which is another situation than erasing information. I can think of examples like child tables with properties useless without the parent record, linking tables (some only hold pairs of keys from two tables), and log tables with various information in child tables. In those cases cascade-delete can safely be turned on for those tables. /gustav