Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:J5z%b.420838$na.810280_at_attbi_s04...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c1ku71$jqu$1_at_news.netins.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:9wd%b.121916$jk2.526707_at_attbi_s53...
> > >
> > > It is a real issue, but I don't agree with the direction you're
taking.
> > >
> > > I think the optimal solution here is to have the constraints specified
> > > declaratively and centrally, but to be able to *additionally* execute
> > > them remotely, i.e., on the client. That last part, on the client, is
> > actually
> > > the least essential place for validation to occur; it's the only one
that
> > > can be omitted. It's always essential to have it enforced centrally,
on
> > the
> > > server, because clients are typically not running on trusted computing
> > > bases.
> > >
> > I agree they should be specified "centrally" but don't necessarily agree
> > with what you mean by that. If you mean that they should be specified
in a
> > way that is tightly coupled with database storage services, I disagree.
>
> To me, the constraints are a subset of the data that the dbms should
manage.

To amplify, if the dbms does not manage integrity, it doesn't manage anything.

> > I would advocate for use of a design that might include an http server
> > with a jvm as the location for all central rules/constraints processing.
>
> This is exactly the architecture that I've worked on every day for the
last
> two years and it doesn't work very well. For one thing, it introduces a
> requirement that all code that will write to the database has to go
through
> the jvm. What do you do about your C++ code? What do you do about
> your code that cannot withstand the occasional garbage collection pause?
> What do you do about third party software you want to integrate that
> is written to use an industry standard interface such as jdbc or odbc?
> It also means that your constraints have to be written manually into
> procedural code instead of specified declaratively, and that means
> bugs, and *that* means corruption and constant maintenance.

Hear! Hear!

> > If the
> > validation should be coded only once (which I agree with), it MUST be
where
> > it is usable by the user interface routines. And if we apply all
integrity
> > logic up front, so that nothing gets past our validation routines into
the
> > database CRUD services, then we don't have to have duplicate logic in
the
> > database, right?
>
> I think the idea of having it be possible to automatically replicate the
> integrity checks on the client (or on whatever earlier tier) is the better
> approach to pursue.

Absolutely, and this argues strongly for a formal representation of integrity constraints that multiple machines can interpret consistently and correctly. Received on Fri Feb 27 2004 - 16:47:24 CET