At 2:50 PM +0000 12/12/08, Colin Guthrie wrote:
'Twas brillig, and tedd at 12/12/08 14:36 did gyre and gimble:
That's neat and a lot more powerful than I thought. It's like
following a linked list to it's end while removing all traces of
the thread.
Exactly
And I understand the "instructor delete" was not intended.
Yeah indeed. I had a db structure in my head and the statement made
vague sense with that in mind, but it totally failed to leak through
my hands on to the keyboard :P
There are three main options here:
* ON DELETE CASCADE (if the FK's referenced table has it's record
deleted, delete the record here too).
* ON DELETE RESTRICT (if the FK's referenced table has it's record
deleted stop that whole transaction - e.g. *prevent* the delete).
* ON DELETE SET NULL (if the FK's referenced table has it's record
deleted, set this tables reference to NULL).
All three are useful in different contexts. I use them extensively
to ensure good data integrity. The trade off on extra load on
insert/update is IMO well worth it.
Col
Col:
That's all good to know.
My first tendency is to keep everything. After all, memory is cheap
and access times are always reducing.
While it's true that having a bunch of worthless data doesn't
accomplish anything and slows the process of dealing with it. But,
technology in access times and storage capabilities are getting to
the point of making the decision to keep/delete worthless data moot.
As such, I think the need for FK deletions will become less and
perhaps disappear from the language. For some reason, I look upon
deletions in similar light as renumbering a table's index after
deletion of a record -- like "what's the point?"
I'm just rambling -- thanks again for your insight.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
