Posted by Tony Rogerson on 02/04/06 20:34

> If you prefer very simple SQL, full control, and cursors then, by all
> means.. views may not be for you.

Why do you associate not using views with cursors?

Views can encapsulate query logic - yes, but you then end up (usually)
nesting views and its then a real bitch to do any performance
tuning/optimisation; i've had this problem a number of times where the
client has made extensive use of views. And to make matters worse they tend
to embed their SQL into the application as well - perhaps its a combined
mindset thing.

If you are continually writing the same 5 join query then you need to
consider if your design is right anyway.

Don't get me wrong - I do use VIEWS in some situations, but I ***NEVER***
allow them to be called directly from the client application, a reporting /
BI tool yes - but thats a different model and you don't usually need to give
end users permissions directly onto the views that make up the model.

Tony Rogerson, SQL Server MVP
http://sqlserverfaq.com


"Serge Rielau" <srielau@ca.ibm.com> wrote in message
news:44hkvuF284scU1@individual.net...
> Doug wrote:
>> Again, a mindset. Could someone help me with why you would prefer a
>> view over a stored procedure? I can almost see the indexed views for
>> the right application, but there has to be a lot of overhead to
>> maintain that indexed view for large tables.
> I think a core question is:
> Do you believe in writing complex SQL (say a 5 way join...).
> If you do, then why would you not want to macro-ize common combinations of
> joins you do over and over again?
> If you prefer very simple SQL, full control, and cursors then, by all
> means.. views may not be for you.
>
> Cheers
> Serge
> --
> Serge Rielau
> DB2 Solutions Development
> DB2 UDB for Linux, Unix, Windows
> IBM Toronto Lab

[Back to original message]