>Hi, Dmitry,
>
>Brandon gave a terrific response on views. His point #3 is perhaps the biggest of all. Big conversions of legacy databases to new databases will often use views in the transition phase, and even beyond that. You'll also find them often in reporting applications.
>
>Generally, what's stored in a view is just the SQL query itself, not the data.
>
>Just wanted to add two additional things
>
>First, in SQL Server (don't know about Oracle), you can't pass parameters to views. There are workarounds (sometimes using table-valued functions), though they tend to be a bit involved.
>
>Second, there's one instance where a view actually "stores" data - a materialized view. It almost sounds like a contradiction in terms. It's not terribly common, but some people use them for fast retrieval of aggregated data. There are several requirements for a materialized view, so you won't seem them often.

Hi Kevin,
Yes, Brandon's message gave me a good understanding of what I didn't know about views. I appreciate your input too. In my case I was not looking for using views for a legacy database. I have a rather complicated case where some data is periodically "sent" to XML files (for user to get and process). I had an idea of replacing the XML files with views. But now that I understand - conceptually - how views work, this approach is not for me.
Thank you.