Re: foundations of relational theory?

Comment, not correction: Since the concept of triggers is mentioned, sure, other MV flavors have triggers as well. Data updates invoke programs, which, as part of the application, serve to update other data, perhaps invoking other triggers in the process. The presence of triggers doesn't guarantee database integrity, triggers are just another tool to centralize application-driven integrity constraints on the database.

Now to Bob's comment: "the whole point of a logical data model is to keep logical integrity issues from becoming implementation specific" - gimme a break... Every relational environment has a different implementation of SQL, different internal file structures, and different mechanisms for managing updates with record locks. Any of these factors are a possible point of failure in a migration. Relational schemas can hardly be considered implementation independent when porting anything but the simplest schema requires changes to any procedures and queries that operate on the data. Oh sure, assuming you've completely re-written the implementation in another environment, all of the data will port. Sheesh, we can do that with any Pick environment too.

Tony

"Andrew McAuley" <amcauley_notreally_at_sprezzatura.com> wrote:

>"Bob Badour" <bbadour_at_golden.net> wrote in message
>news:cd3b3cf.0310270952.592e8214_at_posting.google.com...
>> While this may have eluded your grasp, the whole point of a logical
>> data model is to keep logical integrity issues from becoming
>> implementation specific.
>
>Regretfully you seem to have misunderstood. Whether or not such constraints
>may be enforced at the domain level is "implementation of Pick/MV Vendor"
>specific. Per vendor they are integral and thus ensure logical integrity.
>
Received on Tue Oct 28 2003 - 03:53:05 CET