Re: Cascading Deletes

Todd Taylor wrote:
>
> Kristian Damm Jensen wrote in message
> <3A88F353.1AD0BBAC_at_REMOVEcapgemini.dk>...
> >Todd Taylor wrote:
> >>

<snip>

> >That various parts of the code is depended on each other is nothing new.
> >Of course this requires you to analyse these dependencies when you make
> >changes, which means hard work and risk of forgetting some things. In
> >this specific case the dependency is between program code and DDL, but
> >DDL is code too.
>
> A well architected application will have isolated the impact of this type of
> change.

Agreed. Absolutely

> My point was that if you did not use the cascading delete, then you
> would have had to code in the "delete children then parent" logic to start
> with, and there would have never been an impact on the code.

My point is that I would rather have the DBMS perform this function than something made up by a programmer. There will be no great difference to the application. The difference lies in the dangers of manual updates of the database. And these should be done only be people with the utmost expertise anyway.

> >On the other hand, these dependencies cannot be totally avoided,and if
> >you are trying to avoid it as much as you can, you will have to
> >duplicate code in the system, making it harder to maintain in other
> >aspects.
>
> Well architected applications do not have duplicate code.

Agreed, as said.

A well architected application utilises the features of the underlying tool. :-)

> >As I have said earlier I tend to favour the attitude that the DBMS
> >should do as much work as possible. If then, at the initial design of
> >the system, it makes sense that headers and headerdetails are seen as
> >one entity, then I would use cascading deletes. When the customer
> >arrives with changed specs 2 month later, I will make it clear to him,
> >what the cost of changing ones mind is, then make the revision of the
> >program if he's willing to pay. I will *not* take into account each and
> >every possible change of rule when designing the system.
>
> Your last two statements in this paragraph are very disturbing and I am
> sorry to hear that you take that approach to development. Requirements will
> ALWAYS change. I design my databases and my applications to be flexible to
> change. If there are assumptions to be made, I run them by my clients
> BEFORE I make them so that they are aware of how large an impact a change to
> that part of the system can be. My customers appreciate the fact that they
> can usually come to me with a changes that can be easily implemented.
> Sometimes even some "major" requirements changes can be made with minimal
> effort. Always, always think ahead. It will pay off for you in the end.

I thought I would get a response like that. But note, please, that I said "each and every possible change". I'm not ruling out flexibility.

Design for flexibility, yes.

Think ahead, yes.

Consult the customer on any assumption you can reasonably think up, and even some you think are absurd. Yes.

But when all this has been said and done, I will not let myself be crippled by taking into account possibilities that the customer has explicitly rules out at the initial analysis. I might take them into account anyway, but not if they get in the way of a good design.

The balance between "taking absurd possibilities into account" and "making a good design" is a the heart of this discussion.

<snip>

> In the case that I am not answering a specific point (you say I should just
> delete everything), I generally include all ( or at least the relevant
> portions ) of the previous posts so that readers do not have to find the
> previous post to find out what was being discussed prior to the current
> post. Keep in mind, some newsgroup servers archive postings and referencing
> the previous ones is not possible without doing a search on Deja(oops, I
> mean Google). How convenient is that? However, if that is the way it is
> supposed to be then I will try to do better next time.

I don't know about "supposed to", but it has been the accepted way of quoting since the birth of usenet. As has the custom of snipping anything from the original post no longer relevant to the discussion.

--
Kristian Damm Jensen              | Feed the hungry. Go to 
kristian-damm.jensen_at_capgemini.dk | http://www.thehungersite.com