On Fri, 2008-12-12 at 09:06 +0200, clive wrote: > Colin Guthrie wrote: > > 'Twas brillig, and tedd at 11/12/08 18:46 did gyre and gimble: > >> As for my "Foreign Keys Question", I think the answer is that it > >> enforces rules upon the configuration (i.e., deleting, altering, and > >> such), but does not provide any significant service beyond that. > > > > Well that's a fairly significant service in itself. The whole > > "deleting data" case is where FK's have saved me significant amount of > > coding. > > > > The ON DELETE CASCADE option is key here... "DELETE FROM students > > where student_id=1" will remove all traces of that student from the > > db... all the course they've attended, all the instructors who have > > taught them etc. keeps things nice and tidy without having to put the > > structure in your code all over the place. > > > > Col > > > Is it just me or does anyone else here not like deleting from a > database, I normally have a status field to indicated if a row has been > deleted. > > What about historical data, would you not want to know that studentX was > enrolled at some point in the past, if you just delete that student and > all related data how would you know this? > > You could also have a 2nd database with the same table structure and > move old/delete data into there. It depends on the data. Certainly for student enrolments I would want a paper trail (so to speak) and would just set a status field. But if it was say, an online shopping cart or cached data... I'd just purge it. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
