Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Robert Martin wrote:
> On 2006-06-03 02:02:22 +0200, "Marshall" <marshall.spight_at_gmail.com> said:
>
> > Robert Martin wrote:
> >> On 2006-05-31 13:03:21 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
> >>
> >>> A common misconception among application programmers
> >>> is that their technique of managing integrity with hand written
> >>> code protected by object encapsulation is the equal of
> >>> a centrally managed declarative integrity constraint, and
> >>> that it's merely six of one, half dozen of the other.
> >>
> >> Can you cite a source for this other than your own opinion?
> >
> > This question surprises me. If I had said Java was higher level
> > than assembly, would you have asked for a citation? How
> > would I then respond?
>
> I was asking you to cite a source that it is a "common misconception".
> I don't think it is. I think most application programmers are quite
> convinced that data integrity constraints in the database provide long
> term protection against data mismanagement by the zoo of applications.
> I also think they take the need to manage data *within* their
> applications seriously.

Ah, I see.

I have run in to this attitude many times. This is suggestive of it being a "common" misconception, but is by no means any kind of evidence. I withdraw the characterization "common" and replace it with simple existential quantification.

> > Declarative integrity constraints are better than manually
> > written procedural code for the reasons I list below,
> > and others.
>
> No argument. They are better. They just don't cover all the
> contingencies. Specfically they aren't in effect when the data is
> being actively manipulated in RAM by an application.

Yes. There would be a strong benefit to having a portable way of expressing integrity constraints. The constraints would continue as part of the database, but be able to be queried from and tested within applications. This would make the constraints reusable.

Marshall Received on Tue Jun 13 2006 - 19:31:27 CEST