-Original Message-
From: clive [mailto:clive_li...@immigrationunit.com]
Sent: Friday, December 12, 2008 1:07 AM
To: PHP LIST
Subject: Re: [PHP] Re: Foreign Keys Question
Colin Guthrie wrote:
'Twas brillig, and tedd at 11/12/08 18:46 did gyre and gimble:
As for my Foreign Keys
At 10:24 PM + 12/11/08, 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
'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
At 2:50 PM + 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
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
'Twas brillig, and tedd at 12/12/08 15:16 did gyre and gimble:
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.
At 4:34 PM + 12/12/08, Colin Guthrie wrote:
'Twas brillig, and tedd at 12/12/08 15:16 did gyre and gimble:
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
'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
Colin Guthrie wrote:
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
Micah Gersten wrote:
Colin Guthrie wrote:
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
'Twas brillig, and Chris at 12/12/08 01:20 did gyre and gimble:
Micah Gersten wrote:
Colin Guthrie wrote:
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
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
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
Robert Cummings wrote:
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.
yes - you are right, I was just thinking
14 matches
Mail list logo
