Re: Multiple specification of constraints

Dawn M. Wolthuis wrote:

> "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
>>>> 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.

Indeed it would not sell easily. More importantly I would associate "data integrity engine" more with what just the DBMS does, not whith the (topical) intersection, so luckily they allready exist as part of the CRUD services. But what to call the set of constraints that serve to assists the users in achieving their goal? They are not limited to the workstation. (That is what you mean with WS ?)

> 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.

I'ld want that too - but they are not - at least they are not except in the most trivial situations. Hm... to many hints and negatives and here. Let me rephrase. Only in the most simple of situations C-UA and C-CRUD are the same. (C = type defined in terms of contstraintset, UA = user assistence).

Unfortunately they are generally not the same. But to avoid unnecessary duplication of the intersection, we could/should use the ancient *indirection* trick: create a new original, and have both the old original and the duplicate refer to the new original. If the translation from/into human readable form is done at the right time and the right place, we won't even notice - hey, we only *think* we are writing characters here, while at the lower level we are actually writing ASCII, UTF or whatever bitcodes (assisted by our mailerprogram) that just refer to characters.

> 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.

Even ODBC is capable of delivering a usable set of constraints - at least with Oracle and DB2. Haven't looked into Pg, MySQL or SQLite yet.

Or did I get you wrong, are you looking for something else?

> 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.

I see hurdles in the coordination involved. As soon as there is a reference to a thingy, that thingy is not as free to change as it was before the reference. This goes for charactersets as well as for constraints. Received on Sun Feb 29 2004 - 09:37:48 CET