Re: Multiple specification of constraints

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 27 Feb 2004 10:56:01 -0500
Message-ID: <p8CdnRvXWLRX9aLdRVn-sQ_at_golden.net>

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:BOD%b.67294$Xp.319435_at_attbi_s54... > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1mimq$40n$1_at_news.netins.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:J5z%b.420838$na.810280_at_attbi_s04...
> > >
> > > > 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.
> >
> > These are good points, Marshall. The questions about the difference in
> > language -- whether your C++ code needs to execute DBMS statements that
> > employ the DBMS language specs or have to interface with your Java code
in
> > order to get to the database is a matter of getting implementations to
the
> > point where this is not an issue. There is no conceptual or theory
issue
> > here, but I appreciate the practical issue that needs to be addressed.

>
> Agree on all counts.
>
>

> > The
> > question of whether OO code (those OO types don't like to be called
> > "procedural") or declarative code or whatever language is employed to
"spec"
> > the constraints is somewhat a matter of taste and efficiency. I prefer
> > removal of all declarative code because it is data specified to a
specific
> > database implementation.

>
> That seems strange to me. Using nondeclarative code strikes me as decidely
> inferior, because one needs to write code to enforce each constraint in
> every location where it is applicable, whereas with a declarative

approach,
> one merely has to say what the constraints are, and the enforcement is > automatic.

Do you appreciate the irony of a self-proclaimed mathematician arguing *against* formal languages and symbolic manipulation? Next, she will argue that constructive proofs have little utility.

> > > I agree that user interface is important.
> > >
> > > > I forget who wrote up the story of a major retail chain that built a
new
> > > > store in a certain zip code because their data said a lot of people
go
> > from
> > > > that zip to another to go to this chain. They had to close the
store
> > for
> > > > lack of customers. It turnes out that one of the retail clerks
didn't
> > like
> > > > the constant question of what zip code the buyer was in, so she
always
> > > > entered her own to get past that question. Software usability is
key to
> > > > clean data. The GUI having full knowledge of the business rules
> > > > (validations & all constraints) is critical to a usable GUI.
> > >
> > > I agree that good UI is important. You example, however, illustrates
> > > an error in application design, not with integrity enforcement.
> >
> > Yes, my point was that constraint checking is only part of the picture.
>
> Fair enough.

The part of the picture her espoused model fails at most spectacularly. Her espoused model also fails spectacularly at expressibility among several other fundamental features of sound data management.

> > > 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.
> >
> > Have you seen anyone try to do this? Do they end up with OS-independent
> > applicaxtions? DB-independent? How do they do that? I'm not grasping
the
> > solution to this that includes only one set of validation specifications
and
> > hosts those in a proprietary database engine with a proprietary SQL
> > implementation. It seems that any such solution would make the
application
> > tightly coupled with the database implementation, right?
>
> The only system I've ever seen have any real success with platform independent
> applications is Java. I do not consider C-style portability (i.e., spend a day

> editing header files before you can compile) to be platform independence.
> I suppose .Net has a shot at this same kind of independence; we'll see how
> Mono goes.
>
> But I'm not sure that DB-independence is a real thing today. By way of
> comparison, does OS independence exist? I would say not.

Lee Fesperman once confessed to me to writing system software in Cobol due to its extraordinary portability. Received on Fri Feb 27 2004 - 16:56:01 CET