Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:ZNU%b.135759$jk2.560043_at_attbi_s53...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:btKdnadUYoVY-6LdRVn-gQ_at_golden.net...
> > >
> > > 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.
>
> Yes, exactly my thought. For example, there should be some way to
> have a C++ program "download" constraint logic from the dbms and
> verify it against local data. This might mean a code generation step,
> or it might mean an embedded interpreter, although given how much
> C++ depends on ahead-of-time compilation there might be no point
> to the interpreter. For more dynamic languages, the interpreter might
> even be the language's native interpreter.
>

If we call this current intersection between the constraints/typing that the UI or WS does and what the DBMS does as the "data integrity engine" (produces a lousy acronym, so I don't think it'll catch on ;-) then ideally I would want the run-time environment, the logic applied and the integrity constraints to all be the same, even if we need to apply this twice -- for entering the front door and again for the inner sanctum.

This DIE is then like a distributed DBMS, which can be decoupled from CRUD services, useful for all such purposes. I haven't done much study of Aspect-oriented programming, but I think that might have some relevance to this area (not sure -- I'll have to read a bit more). Otherwise, I really don't hear much from database providers that would do what I looking for, but allowing for the software applications to be written in Java or C# or whatever language is desired.

It seems to me that the DIE could end up with the DBMS's moving that direction or the programming libraries with application servers (J2EE/.NET) -- or both. But continuing our plight of double-coding type information in two different places, two languages, two run-time environments, just doesn't seem wise.

--dawn Received on Sat Feb 28 2004 - 18:24:04 CET