Re: VAT rate or VAT amount as a column?

Ideally the DBMS would make it trivial to change base relations to views and vice-versa with little work (if any). Theoretically, the DBMS could analyze queries and updates and "decide" that all would benefit from having a view (e.g. select ... from X where a=A) become the base relation, and the former base relation split into several new base relations.

All this would need to be strictly transparent, and would probably require administrator approval. I don't believe there's any theoretical reason that users have to know which are base relations and which aren't, so long as view updateability was correct.

• Eric

David Cressey wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:aVlBg.35723$pu3.465389_at_ursa-nb00s0.nbnet.nb.ca...
> > Emily Jones wrote:
> >
> > > A view isn't the same as a base table though is it? Materialised or not.
> >
> > No, a view, by definition, is not a base table. The base tables provide
> > the raw (logical) material from which we construct application views.
> > While each application might view the database as a normalized set of
> > relations, the union of the application views and the base tables
> > generally won't be normalized and will have considerable redundancy.
> >
> > While views are derived from the base tables, though, the base tables
> > are themselves derived from physical storage. Thus it is conceivable
> > that an attribute in a base table will be derived from other stored
> > attributes rather than physically stored itself. That's generally not
> > possible with available SQL dbmses at this time.
>
> I'm not sure I understand the above.
>
> Interbase has a feature called a "computed by" column. Such a column is not
> stored, but is materialied on demand.
> Is this an example of what you are talking about?
Received on Mon Aug 07 2006 - 17:39:11 CEST