[AccessD] Cascade-delete (was: Estimating Help)

Hi John

Very well put.

The funny part is that, if I recall correctly, JC was the first on
this list to stress "never say never" on a very relevant topic.
I have forgot which topic, but it doesn't matter as this statement is
universal when it comes to practical database design.

/gustav


> Hi Gustav,
> I quite responding to a thread when it gets too inflammatory. (Plus, Susan
> implied that it was getting a bit out of hand.) When things get derisive I
> know that no one is going to learn anything. I learned a long time ago that
> some people see things in binary tone and some people see them in continuous
> tone. I've been working in the computer field since 1979 and while that
> certainly doesn't make me an expert at anything it does give me a bit of
> experience. Deriding my physical or mental work habits because I have an
> opposing view isn't going to change my mind on an issue. Debating and
> discussing with someone who is knowledgeable, experienced and of a different
> opinion may well expand the possible solutions that my mind can formulate.
> The way I look at it there's always more than one way to do anything. To me
> its a matter of finding the best solution for each situation. In that
> respect, I disagree with people of the binary tone viewpoint - but I still
> respect them :o)

> As far as cascade delete goes, I tend to agree with many issues covered in
> the thread. I do take exception to the word "never". Just as I would
> disagree with saying never to bound/unbound forms or natural/autonumber
> keys. There is always an exception to every rule so instead I view them as
> "guidelines". In the particular situation I sited, I think cascade delete
> fits the bill much better than using code or queries to delete the child
> records. The parent record WAS able to be deleted by "anyone" using the DB.
> The records were used for formulating ideas or "scenarios" and left in the
> table to avoid having to recreate the same scenario at a later date. Only 1
> would be chosen and used for any particular case. So essentially the records
> not chosen could be viewed later and certain parameters could be modified
> for more "brainstorming" scenarios, thus preventing the NEED to re-enter of
> bunch of mundane detail data. It is one example where using an Access DB is
> actually more powerful than some major DBs because I don't have to specify
> that every program using the BE DB must write procedures to clean up these
> unused child records when deleting a un-chosen scenario. The reality of the
> situation is that just because someone has a degree and/or experience using
> a GIS doesn't mean they understand relational databases, Access queries or
> VB code. Until recently the major GIS platform used in the USA used a flat
> file database and an application specific macro language. Now we're pushing
> and pulling MBs of spatial data into and out of Access DBs and using VBA!

> Cascade Delete certainly can be dangerous but like someone famous once said:
> "with great power comes great responsibility"!

> John B.
> "In Wisconsin, in the winter, in my office, in the basement...
> nothing is black and white here."

> -----Original Message-----
> From: accessd-admin at databaseadvisors.com
> [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Gustav Brock
> Sent: Wednesday, February 05, 2003 5:55 AM
> To: Arthur Fuller
> Subject: Re: [AccessD] Cascade-delete (was: Estimating Help)


> Hi Arthur

>> Speaking only for myself, I use cascade frequently delete, wherever it's
>> appropriate. When I began this thread, I didn't mention cascade delete at
>> all. I very specifically said "rows disappearing from reports" -- not from
>> tables. This was an RI issue, not a cascade issue. However, since I have
>> been known to rant, carry on :-)

> Hmmm ... nice try. And it brought some relief.

> But [picky mode on] you did start the thread - I couldn't read this in
> more than one way:

>> I didn't mean that the rows were disappearing, but rather that they
>> disappeared from reports, since their FK referents were gone. I would
>> never
>> be so foolish as to turn cascade-delete on anywhere in any serious
>> database :-)
>> I restored an old copy with the deleted employees, then imported the
>> rows and restored sanity to the db.

> /gustav