At 03:41 AM 7/06/2005 +0000, Mick wrote:

> > -Philip
>Creating a View is a Data Definition task.

Yes. Needs to be committed before it can be used.

>Selecting data is a Data Manipulation task.

Yes. Manipulates data in objects (tables, views).

>They cannot be mixed in the same transaction.

Can be, but definitely should NOT be. Metadata definitions are stored in
database tables so there's a line of thinking that says, "OK, if my
transaction can see the definition, it should be able pump stuff into the
object." Well, it sort-of can but the results will be compost.

>Changing db Meta data whilst other users are connected is fraught with
>danger, there are two ways to learn this either listen to me or do as
>I did.

Listen to Mick.

>A view is at heart a select without a where clause (also no triggers...).

A view can have a where clause and triggers. What it can't have is an
ORDER BY clause.

>You can make a select in your client that acts like a view with the
>added advantage that you can constrain (add a where clause) your
>result set.

Better still, that same select in your client CAN be over a view, including
one that is already constrained by a WHERE and/or GROUP BY clause (and can
be a UNION, if you want).

The benefit of views is that they are nothing but definitions. They don't
store any data of their own, so you can have as many as you need. You can
join a view with tables or with other views; you can define views that do
this; etc. etc. If you are smart about the indexing in the underlying
tables, views need not perform worse than the queries underlying them.

So, like others, I'm really curious to understand why you think it's
important to be able to create views on the fly...

./heLen