Performance of Tables vs. Views

Question

Recently started working with a database in which the convention is to create a view for every table. If you assume that there is a one to one mapping between tables and views,

Answer 1

Assuming the question is about non-materialized views -- Really depends on the query that the view is based on, and what is being done to it. Sometimes, the predicates can be pushed into the view query by the optimizer. If not, then it wouldn't be as good as against the table itself. Views are built on top of tables -- why would you expect that the performance would be better?

Layering views, where you build one view on top of another, is a bad practice because you won't know about issues until run time. It's also less of a chance that predicate pushing will occur with layered views.

Views can also be updateable -- they aren't a reliable means to restricting access to resources if someone has INSERT/UPDATE/DELETE privileges on the underlying tables.

Materialized views are as good as tables, but are notoriously restrictive in what they support.

Answer 2

You don't explain what you're doing in the views? A 1:1 with the tables sounds like you are using the views more like synonyms than a view. IOW, are the views = "SELECT * FROM table", then you'll see no performance hit except on hard parse.

If you are joining to other tables or placing filter clauses in them which prevent predicate pushing than you're bound to see a major hit sometime.

Answer 3

The only pain I have had with views is a distributed query over a DB link. The local optimizer gets some details about the remote object, but the view doesn't tell it about any indexes so you can get some kooky plans.

I've heard about some places that use it as a standard since they can easily 're-order' the columns in a view. Not a big benefit in my opinion by YMMV