Re: What should be the Database Design in this case?

From: Bob Badour <bbadour_at_golden.net>
Date: Mon, 9 Dec 2002 20:39:57 -0500
Message-ID: <REbJ9.529$zO7.47254650_at_radon.golden.net>


"--CELKO--" <71062.1056_at_compuserve.com> wrote in message news:c0d87ec0.0212090936.79a9922_at_posting.google.com...
> >> Joe, I respectfully disagree. The relational model says nothing
> about how,
> where or how often one stores anything. Storage is physical. Even
> creating an index generally increases redundant storage. <<
>
> >> Whether one creates a view or a snapshot, the logical
> representation has exactly the same redundancy. <<
>
> Snapshots are frozen at a moment in time and are base tables.

Joe, I respectfully disagree on both counts. Snapshots are derived, stored relations. Derived relations--by definition--are not base relations. I expect a full featured dbms to support one-shot snapshots, periodic snapshots and continuous snapshots. I also expect a full featured dbms to allow lazy updates to any of the three types.

A casual user should not be able to distinguish between a base table, a view and a continuous snapshot, nor should the casual user care about the difference.

> Views
> are built each time they are invoked and can change during a session,
> depending on your transaction level.

I would hope that views are not 'built' at all. They should simply contribute to the overall relational expression prior optimization and evaluation. I see no reason to 'build' a multi-billion row cartesian product to evaluate a contradiction.

> Big logical and practical
> differences!

I agree that logical differences are big and practical. The difference between logical and physical is even bigger and even more practical.

> If I build a base table to hold summary data, it is logically
> redundant because it can be calculated from the details that were
> summaried. If I create A VIEW (i.e. a virtual table taking up no
> storage when not in use), then the summary is always right at the time
> of invocation.

At the logical level, the base table and the view have exactly the same redundancy as an equivalent snapshot would. The dbms will ensure the snapshot is always right at the time of invocation. Regardless, the view has no lesser logical redundancy.

> To guarantee that a base table, would always be
> current, I would need a constraint and some kind of action (i.e.
> triggers or stored procedure) that was guuaranteed to be applied each
> and every time a detail was changed.

Which is why I originally mentioned a snapshot and a view, and why I did not mention a base table. Received on Tue Dec 10 2002 - 02:39:57 CET

Original text of this message