In my enrollment database, we keep historical information. My client is a big computer training organization (for which I also teach). The enrollment information is quite fluid -- people are always canceling or rescheduling. It is important for us to know a person's history.

$.02

Ken

On Dec 12, 2008, at 9:16 AM, tedd wrote:

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



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to