Re: foundations of relational theory?
Date: Mon, 27 Oct 2003 18:53:05 -0800
Message-ID: <ndjrpvgdq9n3f3t0tpi3hcddom1910aohm_at_4ax.com>
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