Fedor Karpelevitch wrote:
>
> > > I do not know very many databases but of those I know only
> > Oracle supports
> > > CASCADE for example (do you know others?), does MySQL?, etc...
> >
> > MySQL does not trouble itself such baroque and performance
> > imparing features ;-)
> > No transactions, no foreign keys, no constraints, no
> > triggers... pure readonly
> > performance. Just what you need for a running a website (but
> > not a web-interfaced
> > application)
> >
> > > I think we do not need to support it HERE, I believe in
> > most cases it would
> > > be preferrable to perform appropriate action (i.e. cascade delete)
> > > programmatically in java. It might even Make sense to add
> > methods such as
> > > doDeleteCascade to Peers so that it does the cascade delete
> > and doDelete
> > > will raise an exception if you are trying to delete a row with child
> > > records.
> >
> > We have the meta information, so we might attempt doing that. But on
> > transaction-less db engines, it's still failure prone. The good thing
> > is that it would minimise the programmer's error factor.
>
> If you tolerate absense of transactions in other cases this should not be an
> exclusion. It is as error prone as anything else, but at least it minimizes
> the human factor which is more dangerous than any power failure ;-)
>
> >
> > > Alternatively we can add a parameter to doDelete and doUpdate to
> > > tell it whether it should be cascaded or not. I think this
> > way you'll have
> > > much better and granular control over this (dangerous)
> > behaviour. Makes
> > > sense?
> >
> > +1.
> >
> > The crucial part is to fall back to programmatic cascading
> > only when the
> > DB does not support cascades.
>
> I think it's a good idea in any case because DB support does not give you
> the control over this behaviour. You can only define it when you create the
> table. If you, however, use programmatic implementation you explicitly
> specify whether you want to delete the record only if it has no children
> or delete any children if there are. An example would be some financial app
> where a Clerk would only be able to delete an empty bill (created by
> mistake) while a Supervisor would be able to delete any bill whether empty
> or not (do not critisize the example).
>
> Fedor.
>
Fedor, I am going to disagree here simply because that is not the intent
of the CASCADE option in a delete situation within a properly normalized
(or normalized and then optimized) database.
Deleting a single empty mistaken bill is a bogus example. Here is a real
world example from a place I previously worked:
We managed medical transcription output for doctors. Within the system,
medical records are assured privacy and by contractual agreement, if a
physician leaves our network, we are obligated to remove all historical
records of his that we kept online. So, rather than writing a cumbersome
and possibly error prone program to do such a trivial task, I setup all
tables that were dependent on the physician's id code to cascade delete.
Thus if I delete physician 12345 from the physician table, all of his
dictations are deleted from the dictation table, all of the XML outputs
are deleted from the transcription table, all of the voice models for
that physician are deleted from the voice model table, all of the
document templates are deleted from the template table, etc.
In short, the cascading delete is a way to ensure that DEPENDENT data is
removed from the database when the foreign key upon which it depends is
removed from the database. This bypasses the need to code specialized
delete programs, it reduces tendency of bugs in such programs to damage
the database, and it preserves referential integrity within the
database.
I don't think your arguments for what you propose are good at all except
in databases that do not support a cascading action of one sort or
another. In fact, I am very certain that such "granularity" will lead to
referential integrity errors as mistakes are made in specifying deletion
chains by programmers.
--
==============================================================
"Always listen to experts. They'll tell you what can't be
done, and why. Then do it."
-- Lazarus Long, in Robert Heinlein's Time Enough for Love
==============================================================
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
