|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Views vs Stored Procedures?Jerry,
A VIEW is a virtual table -- you can select, update, delete, insert, just like a regular table. A STORED PROCEDURE is a procedure -- it does something. You cannot update it, only run it. Pardon the cliche, but it's really like comparing apples and oranges. Please be more specific about your problem. -- Alex Papadimoulis Show quote "Jerry" wrote: > Anybody knows the pros and cons of using Views vs Stored Procedures? Views and stored procedures are two different objects, and I don't prefer to
compare them. Views are meant for presenting data to different users in different ways, for controlling access to data and base tables, and to simplify the queries by embedding comples queries in the view definition. Whereas stored procedures are a block of code, that can be a combination of many queries and control flow statements. If you are coming from a programming background, you could think of procedures as functions/modules. Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... > Anybody knows the pros and cons of using Views vs Stored Procedures? i meant in terms of Perfomance...
CREATE VIEW AS SELECT A,B,C FROM TABLE or CREATE PROCEDURE SELECT A,B,C FROM TABLE Show quote "Narayana Vyas Kondreddi" wrote: > Views and stored procedures are two different objects, and I don't prefer to > compare them. Views are meant for presenting data to different users in > different ways, for controlling access to data and base tables, and to > simplify the queries by embedding comples queries in the view definition. > Whereas stored procedures are a block of code, that can be a combination of > many queries and control flow statements. If you are coming from a > programming background, you could think of procedures as functions/modules. > -- > Vyas, MVP (SQL Server) > SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ > > > "Jerry" <Je***@discussions.microsoft.com> wrote in message > news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... > > Anybody knows the pros and cons of using Views vs Stored Procedures? > > > In that particular situation I don't see much of a performance difference.
What will make the difference here is an index on your Table to prevent a Table Scan. Do you have a more specific example of what you're trying to do, or was this it? Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >i meant in terms of Perfomance... > > CREATE VIEW AS SELECT A,B,C FROM TABLE > > or > CREATE PROCEDURE > SELECT A,B,C FROM TABLE > "Narayana Vyas Kondreddi" wrote: > >> Views and stored procedures are two different objects, and I don't prefer >> to >> compare them. Views are meant for presenting data to different users in >> different ways, for controlling access to data and base tables, and to >> simplify the queries by embedding comples queries in the view definition. >> Whereas stored procedures are a block of code, that can be a combination >> of >> many queries and control flow statements. If you are coming from a >> programming background, you could think of procedures as >> functions/modules. >> -- >> Vyas, MVP (SQL Server) >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >> > Anybody knows the pros and cons of using Views vs Stored Procedures? >> >> >> The view can have an index.
and we can use the table's index in the procedure Show quote "Michael C#" wrote: > In that particular situation I don't see much of a performance difference. > What will make the difference here is an index on your Table to prevent a > Table Scan. > > Do you have a more specific example of what you're trying to do, or was this > it? > > "Jerry" <Je***@discussions.microsoft.com> wrote in message > news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... > >i meant in terms of Perfomance... > > > > CREATE VIEW AS SELECT A,B,C FROM TABLE > > > > or > > CREATE PROCEDURE > > SELECT A,B,C FROM TABLE > > "Narayana Vyas Kondreddi" wrote: > > > >> Views and stored procedures are two different objects, and I don't prefer > >> to > >> compare them. Views are meant for presenting data to different users in > >> different ways, for controlling access to data and base tables, and to > >> simplify the queries by embedding comples queries in the view definition. > >> Whereas stored procedures are a block of code, that can be a combination > >> of > >> many queries and control flow statements. If you are coming from a > >> programming background, you could think of procedures as > >> functions/modules. > >> -- > >> Vyas, MVP (SQL Server) > >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ > >> > >> > >> "Jerry" <Je***@discussions.microsoft.com> wrote in message > >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... > >> > Anybody knows the pros and cons of using Views vs Stored Procedures? > >> > >> > >> > > > CREATE VIEW AS SELECT A,B,C FROM TABLE
Doesn't create an Indexed View. CREATE PROCEDURE SELECT A,B,C FROM TABLE Doesn't specify the DDL of the Table. So, based on your example, net sum is zero. Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:68BFE4A6-431F-4908-A750-349B2C80DB6C@microsoft.com... > The view can have an index. > > and we can use the table's index in the procedure > > "Michael C#" wrote: > >> In that particular situation I don't see much of a performance >> difference. >> What will make the difference here is an index on your Table to prevent a >> Table Scan. >> >> Do you have a more specific example of what you're trying to do, or was >> this >> it? >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >> >i meant in terms of Perfomance... >> > >> > CREATE VIEW AS SELECT A,B,C FROM TABLE >> > >> > or >> > CREATE PROCEDURE >> > SELECT A,B,C FROM TABLE >> > "Narayana Vyas Kondreddi" wrote: >> > >> >> Views and stored procedures are two different objects, and I don't >> >> prefer >> >> to >> >> compare them. Views are meant for presenting data to different users >> >> in >> >> different ways, for controlling access to data and base tables, and to >> >> simplify the queries by embedding comples queries in the view >> >> definition. >> >> Whereas stored procedures are a block of code, that can be a >> >> combination >> >> of >> >> many queries and control flow statements. If you are coming from a >> >> programming background, you could think of procedures as >> >> functions/modules. >> >> -- >> >> Vyas, MVP (SQL Server) >> >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >> >> >> >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >> >> > Anybody knows the pros and cons of using Views vs Stored Procedures? >> >> >> >> >> >> >> >> >> Personally I don't like to work with views, specailly if data size is huge.
They are slowing down a lot and utlizing resources too. Generally, whenever you call a view, first thing that SQL does is to create and go through the scan for all records on that view and then the rest... so imagine if the datasize is large then it will take tiime ad resources to create the view. Now if your view is a complex select with many joins, then it will be worst. Prevent using views, and use them only if you are forced to use. Pat Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >i meant in terms of Perfomance... > > CREATE VIEW AS SELECT A,B,C FROM TABLE > > or > CREATE PROCEDURE > SELECT A,B,C FROM TABLE > "Narayana Vyas Kondreddi" wrote: > >> Views and stored procedures are two different objects, and I don't prefer >> to >> compare them. Views are meant for presenting data to different users in >> different ways, for controlling access to data and base tables, and to >> simplify the queries by embedding comples queries in the view definition. >> Whereas stored procedures are a block of code, that can be a combination >> of >> many queries and control flow statements. If you are coming from a >> programming background, you could think of procedures as >> functions/modules. >> -- >> Vyas, MVP (SQL Server) >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >> > Anybody knows the pros and cons of using Views vs Stored Procedures? >> >> >> And how you can merge results from two sp?
in the case of views is pretty easy. select a,b,c from View1, View2 where View2.f = View1.f? Is any recomendation, best practices from MS about when is better use one apporach or the other? Show quote "Patrick" wrote: > Personally I don't like to work with views, specailly if data size is huge. > They are slowing down a lot and utlizing resources too. > > Generally, whenever you call a view, first thing that SQL does is to create > and go through the scan for all records on that view and then the rest... so > imagine if the datasize is large then it will take tiime ad resources to > create the view. Now if your view is a complex select with many joins, then > it will be worst. > > Prevent using views, and use them only if you are forced to use. > > Pat > > > "Jerry" <Je***@discussions.microsoft.com> wrote in message > news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... > >i meant in terms of Perfomance... > > > > CREATE VIEW AS SELECT A,B,C FROM TABLE > > > > or > > CREATE PROCEDURE > > SELECT A,B,C FROM TABLE > > "Narayana Vyas Kondreddi" wrote: > > > >> Views and stored procedures are two different objects, and I don't prefer > >> to > >> compare them. Views are meant for presenting data to different users in > >> different ways, for controlling access to data and base tables, and to > >> simplify the queries by embedding comples queries in the view definition. > >> Whereas stored procedures are a block of code, that can be a combination > >> of > >> many queries and control flow statements. If you are coming from a > >> programming background, you could think of procedures as > >> functions/modules. > >> -- > >> Vyas, MVP (SQL Server) > >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ > >> > >> > >> "Jerry" <Je***@discussions.microsoft.com> wrote in message > >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... > >> > Anybody knows the pros and cons of using Views vs Stored Procedures? > >> > >> > >> > > > If you need to 'merge' the results, that is an indication that maybe you
need views and not stored procedures. Views have a single result set of rows; stored procedures don't always have a result set, and sometimes they may have several or many result sets. If your stored procedure returns a single result set, you can capture those rows in a table, if you have already created the table: INSERT INTO mytable EXEC myproc So you could do that with two procs, and two tables, and then join the two tables. But again, if that's what you need to do, you should consider views instead. But, it really depends on the details of what you're trying to do. The more details you can provide, the more help you can receive. Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:60A0B9F0-B3C4-4C74-8C11-5F386E3AF9C4@microsoft.com... > And how you can merge results from two sp? > in the case of views is pretty easy. > select a,b,c from View1, View2 where View2.f = View1.f? > > Is any recomendation, best practices from MS about when is better use one > apporach or the other? > > "Patrick" wrote: > >> Personally I don't like to work with views, specailly if data size is >> huge. >> They are slowing down a lot and utlizing resources too. >> >> Generally, whenever you call a view, first thing that SQL does is to >> create >> and go through the scan for all records on that view and then the rest... >> so >> imagine if the datasize is large then it will take tiime ad resources to >> create the view. Now if your view is a complex select with many joins, >> then >> it will be worst. >> >> Prevent using views, and use them only if you are forced to use. >> >> Pat >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >> >i meant in terms of Perfomance... >> > >> > CREATE VIEW AS SELECT A,B,C FROM TABLE >> > >> > or >> > CREATE PROCEDURE >> > SELECT A,B,C FROM TABLE >> > "Narayana Vyas Kondreddi" wrote: >> > >> >> Views and stored procedures are two different objects, and I don't >> >> prefer >> >> to >> >> compare them. Views are meant for presenting data to different users >> >> in >> >> different ways, for controlling access to data and base tables, and to >> >> simplify the queries by embedding comples queries in the view >> >> definition. >> >> Whereas stored procedures are a block of code, that can be a >> >> combination >> >> of >> >> many queries and control flow statements. If you are coming from a >> >> programming background, you could think of procedures as >> >> functions/modules. >> >> -- >> >> Vyas, MVP (SQL Server) >> >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >> >> >> >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >> >> > Anybody knows the pros and cons of using Views vs Stored Procedures? >> >> >> >> >> >> >> >> >> If this is a union then use UNION
or join you can user INNER JOIN depends on your situation. Show quote "Jerry" <Je***@discussions.microsoft.com> wrote in message news:60A0B9F0-B3C4-4C74-8C11-5F386E3AF9C4@microsoft.com... > And how you can merge results from two sp? > in the case of views is pretty easy. > select a,b,c from View1, View2 where View2.f = View1.f? > > Is any recomendation, best practices from MS about when is better use one > apporach or the other? > > "Patrick" wrote: > >> Personally I don't like to work with views, specailly if data size is >> huge. >> They are slowing down a lot and utlizing resources too. >> >> Generally, whenever you call a view, first thing that SQL does is to >> create >> and go through the scan for all records on that view and then the rest... >> so >> imagine if the datasize is large then it will take tiime ad resources to >> create the view. Now if your view is a complex select with many joins, >> then >> it will be worst. >> >> Prevent using views, and use them only if you are forced to use. >> >> Pat >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >> >i meant in terms of Perfomance... >> > >> > CREATE VIEW AS SELECT A,B,C FROM TABLE >> > >> > or >> > CREATE PROCEDURE >> > SELECT A,B,C FROM TABLE >> > "Narayana Vyas Kondreddi" wrote: >> > >> >> Views and stored procedures are two different objects, and I don't >> >> prefer >> >> to >> >> compare them. Views are meant for presenting data to different users >> >> in >> >> different ways, for controlling access to data and base tables, and to >> >> simplify the queries by embedding comples queries in the view >> >> definition. >> >> Whereas stored procedures are a block of code, that can be a >> >> combination >> >> of >> >> many queries and control flow statements. If you are coming from a >> >> programming background, you could think of procedures as >> >> functions/modules. >> >> -- >> >> Vyas, MVP (SQL Server) >> >> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >> >> >> >> >> >> "Jerry" <Je***@discussions.microsoft.com> wrote in message >> >> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >> >> > Anybody knows the pros and cons of using Views vs Stored Procedures? >> >> >> >> >> >> >> >> >> This is not true.
The first thing SQL Server does when you have a view in your query is to translate it into the underlying definition, and then your query will be processed EXACTLY the same as if you didn't have the view, but used the SQL that makes up the view definition instead. If you have good indexes on your tables, they will be used even if you access the data through a view. If you view is complex with many joins, why did you create it that way, if you don't need all those tables joined. If you need to join the tables, it's no worse going through a view than NOT going through the view. The reason for views is not for performance; it is to simply your code and your security settings. (Now there is the matter of indexed views, which is another topic, but frequently SQL Server goes through the same steps as above even if there is an indexed view.) Show quote "Patrick" <patria***@gmail.com> wrote in message news:%23$e36doWFHA.2692@TK2MSFTNGP15.phx.gbl... > Personally I don't like to work with views, specailly if data size is > huge. They are slowing down a lot and utlizing resources too. > > Generally, whenever you call a view, first thing that SQL does is to > create and go through the scan for all records on that view and then the > rest... so imagine if the datasize is large then it will take tiime ad > resources to create the view. Now if your view is a complex select with > many joins, then it will be worst. > > Prevent using views, and use them only if you are forced to use. > > Pat > > > "Jerry" <Je***@discussions.microsoft.com> wrote in message > news:4D58689E-5F9D-4EA8-BBBC-58780D7C1D7B@microsoft.com... >>i meant in terms of Perfomance... >> >> CREATE VIEW AS SELECT A,B,C FROM TABLE >> >> or >> CREATE PROCEDURE >> SELECT A,B,C FROM TABLE >> "Narayana Vyas Kondreddi" wrote: >> >>> Views and stored procedures are two different objects, and I don't >>> prefer to >>> compare them. Views are meant for presenting data to different users in >>> different ways, for controlling access to data and base tables, and to >>> simplify the queries by embedding comples queries in the view >>> definition. >>> Whereas stored procedures are a block of code, that can be a combination >>> of >>> many queries and control flow statements. If you are coming from a >>> programming background, you could think of procedures as >>> functions/modules. >>> -- >>> Vyas, MVP (SQL Server) >>> SQL Server Articles and Code Samples @ http://vyaskn.tripod.com/ >>> >>> >>> "Jerry" <Je***@discussions.microsoft.com> wrote in message >>> news:6377A3C2-FBE0-4844-8056-3181BD33043D@microsoft.com... >>> > Anybody knows the pros and cons of using Views vs Stored Procedures? >>> >>> >>> > > Kalen Delaney wrote:
> This is not true. Does the abovesaid mean that precompiled execution> The first thing SQL Server does when you have a view in your query is to > translate it into the underlying definition, and then your query will be > processed EXACTLY the same as if you didn't have the view, but used the SQL > that makes up the view definition instead. plan is another aspect which makes views and SPs different? Yes.
-- Show quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ "Sericinus hunter" <serh***@flash.net> wrote in message news:6Emie.2653$tX5.745@newssvr33.news.prodigy.com... > Kalen Delaney wrote: >> This is not true. >> The first thing SQL Server does when you have a view in your query is to translate it into the >> underlying definition, and then your query will be processed EXACTLY the same as if you didn't >> have the view, but used the SQL that makes up the view definition instead. > > Does the abovesaid mean that precompiled execution > plan is another aspect which makes views and SPs different? They are different in the way the plans are saved, recompiled and reused,
but that doesn't mean one is better than the other. The plan from a view can be reused because in SQL Server 2000 any plan can be reused. But reuse is not always a good thing. Show quote "Sericinus hunter" <serh***@flash.net> wrote in message news:6Emie.2653$tX5.745@newssvr33.news.prodigy.com... > Kalen Delaney wrote: >> This is not true. >> The first thing SQL Server does when you have a view in your query is to >> translate it into the underlying definition, and then your query will be >> processed EXACTLY the same as if you didn't have the view, but used the >> SQL that makes up the view definition instead. > > Does the abovesaid mean that precompiled execution > plan is another aspect which makes views and SPs different? Kalen Delaney wrote:
> They are different in the way the plans are saved, recompiled and reused, Can you verify or clarify this statement concerning execution plan> but that doesn't mean one is better than the other. > > The plan from a view can be reused because in SQL Server 2000 any plan can > be reused. But reuse is not always a good thing. for views? Here is citation from the Vieira book: "Be aware that, by default, there is nothing special done for a view. The view runs just as if it were run from the command line -- there is no pre-optimization of any kind." I am sure we may have different things in mind, but I would like to get a clear picture. [...my news client rightfully did not quote anything below signature...] It's not that it's a view that a plan can be reused. The view is processed
as it it were just a query, and the plan for any query can be reused. The SQL Server Books Online, under "Scalability and Availability" says this: The query optimizer natively supports the prepare/execute model of executing SQL statements. When an application executes an SQL statement, the optimizer has efficient algorithms for determining if the same statement has already been executed by any application. If the optimizer finds an existing execution plan for the statement, it saves processing resources by reusing the existing plan instead of compiling a new plan. In systems where many users are running the same application, this can reduce the resources needed to compile SQL statements into execution plans. Also, in the Delaney book, Inside SQL Server, there is a whole section on the different ways query plans can be reused in Chapter 15. Show quote "Sericinus hunter" <serh***@flash.net> wrote in message news:R7Iie.3863$tX5.2990@newssvr33.news.prodigy.com... > Kalen Delaney wrote: >> They are different in the way the plans are saved, recompiled and reused, >> but that doesn't mean one is better than the other. >> >> The plan from a view can be reused because in SQL Server 2000 any plan >> can be reused. But reuse is not always a good thing. > > Can you verify or clarify this statement concerning execution plan > for views? > > Here is citation from the Vieira book: > "Be aware that, by default, there is nothing special done for a view. > The view runs just as if it were run from the command line -- there > is no pre-optimization of any kind." > > I am sure we may have different things in mind, but I would like > to get a clear picture. > > [...my news client rightfully did not quote anything below signature...] According to BOL for SQL Server 2000 stored procedures have been optimised
for data processing tasks such insert, update and deletes. Views and especially functions have been optimised for presenting data. I believe with SQL Server 7 and earlier this wasn't the case and it wasn't so clear cut as to whether to use stored procedures or views. Justin Show quote "Kalen Delaney" wrote: > It's not that it's a view that a plan can be reused. The view is processed > as it it were just a query, and the plan for any query can be reused. > > The SQL Server Books Online, under "Scalability and Availability" says this: > > The query optimizer natively supports the prepare/execute model of executing > SQL statements. When an application executes an SQL statement, the optimizer > has efficient algorithms for determining if the same statement has already > been executed by any application. If the optimizer finds an existing > execution plan for the statement, it saves processing resources by reusing > the existing plan instead of compiling a new plan. In systems where many > users are running the same application, this can reduce the resources needed > to compile SQL statements into execution plans. > > Also, in the Delaney book, Inside SQL Server, there is a whole section on > the different ways query plans can be reused in Chapter 15. > > -- > HTH > ---------------- > Kalen Delaney > SQL Server MVP > www.SolidQualityLearning.com > > > "Sericinus hunter" <serh***@flash.net> wrote in message > news:R7Iie.3863$tX5.2990@newssvr33.news.prodigy.com... > > Kalen Delaney wrote: > >> They are different in the way the plans are saved, recompiled and reused, > >> but that doesn't mean one is better than the other. > >> > >> The plan from a view can be reused because in SQL Server 2000 any plan > >> can be reused. But reuse is not always a good thing. > > > > Can you verify or clarify this statement concerning execution plan > > for views? > > > > Here is citation from the Vieira book: > > "Be aware that, by default, there is nothing special done for a view. > > The view runs just as if it were run from the command line -- there > > is no pre-optimization of any kind." > > > > I am sure we may have different things in mind, but I would like > > to get a clear picture. > > > > [...my news client rightfully did not quote anything below signature...] > > > Given the OP's two examples for comparison, you're not going to see much of
a difference in performance either way. Show quote "JAT" <J**@discussions.microsoft.com> wrote in message news:C4D330F0-554F-4552-AC0A-E98C6E155ECE@microsoft.com... > According to BOL for SQL Server 2000 stored procedures have been optimised > for data processing tasks such insert, update and deletes. Views and > especially functions have been optimised for presenting data. > > I believe with SQL Server 7 and earlier this wasn't the case and it wasn't > so clear cut as to whether to use stored procedures or views. > > Justin > > "Kalen Delaney" wrote: > >> It's not that it's a view that a plan can be reused. The view is >> processed >> as it it were just a query, and the plan for any query can be reused. >> >> The SQL Server Books Online, under "Scalability and Availability" says >> this: >> >> The query optimizer natively supports the prepare/execute model of >> executing >> SQL statements. When an application executes an SQL statement, the >> optimizer >> has efficient algorithms for determining if the same statement has >> already >> been executed by any application. If the optimizer finds an existing >> execution plan for the statement, it saves processing resources by >> reusing >> the existing plan instead of compiling a new plan. In systems where many >> users are running the same application, this can reduce the resources >> needed >> to compile SQL statements into execution plans. >> >> Also, in the Delaney book, Inside SQL Server, there is a whole section on >> the different ways query plans can be reused in Chapter 15. >> >> -- >> HTH >> ---------------- >> Kalen Delaney >> SQL Server MVP >> www.SolidQualityLearning.com >> >> >> "Sericinus hunter" <serh***@flash.net> wrote in message >> news:R7Iie.3863$tX5.2990@newssvr33.news.prodigy.com... >> > Kalen Delaney wrote: >> >> They are different in the way the plans are saved, recompiled and >> >> reused, >> >> but that doesn't mean one is better than the other. >> >> >> >> The plan from a view can be reused because in SQL Server 2000 any plan >> >> can be reused. But reuse is not always a good thing. >> > >> > Can you verify or clarify this statement concerning execution plan >> > for views? >> > >> > Here is citation from the Vieira book: >> > "Be aware that, by default, there is nothing special done for a view. >> > The view runs just as if it were run from the command line -- there >> > is no pre-optimization of any kind." >> > >> > I am sure we may have different things in mind, but I would like >> > to get a clear picture. >> > >> > [...my news client rightfully did not quote anything below >> > signature...] >> >> >>  |
|||||||||||||||||||||||
Other interesting topics