Query Rewrite with regular database Views

Question

Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. However, query rewrite doesn't work no matter how I define the MV and View. Here's an example:
I've Sales tables with columns: PDate, CustCode, Amount
and Customer table with columns: CustCode, CustDesc
I create a view SALES_V with columns: PDate, CustCode, CustDesc, Amount by joining Sales table with Customer table as follows:
create or replace view SALES_V as
select PDate, c.CustCode, c.CustDesc, Amount
from Sales s
join Customer c on (s.CustCode=c.CustCode);
For the sake of speed, I create a materialized view SALES_TOT_MV with columns: PDate, Amount with the following SQL:
create materialized view SALES_TOT_MV
enable query rewrite
as select PDate, sum(Amount) Amount from Sales
group by PDate;
When I run the following query, I expect it to be rewritten to make use of SALES_TOT_MV:
select PDate, sum(Amount) from SALES_V
group by PDate;
However, explain plan always tell me it's using SALES table, not the SALES_TOT_MV.
Can somebody tell me it's a limitation of Oracle optimizer or I'm just missing something for this?
Thanks in advance!!
- Andrew
Edited by: blackhole001 on Jan 28, 2010 12:34 PM

Answer 1

blackhole001 wrote:
Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. This sounds like a pretty horrible idea. I say this because you will eventually end up with programmers that know nothing about your data model and how to properly interact with it.
Additionally, what you will get is a developer that takes one of your views and see's that of the 20 columns in it, it has 4 that he needs. If all those 4 columns comes from a simple 2 table join, but the view has 8 tables, you're wasting a tonne of resources by using the view (and heaven forbid they have to join that view to another view to get 4 of the 20 columns from that other view as well).
Ideally you'd write stored routines that satisfy exactly what is required (if you are the database resource and these other programmers are java, .net, etc... based) and the front end developers would call those routines customized for an exact purpose.
Creating views is not bad, but it's by no means a proper solution to having developers not learn or understand SQL and/or the data model.