InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 21:31:41 GMT20http://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]BaldingLoopMan (12/9/2009)[/b][hr]not sure what ur saying about the selecting for a cte because u can sdo that w/ the #tables as well.I like the #tables in development because i can see what is in them after the process runs and so on[/quote]Right, I was just saying that you could do the same with CTE's, not that you COULDN'T do it with temp tables. The way your statement read, it seemed like you were arguing that as a reason to use temp tables instead of CTE's. Granted, because of the single query limitations of CTE's, you can't do 20 different operations to them and then view them as easily as you could a temp table (although CTE's can refer to any cte above them, so you can do multiple operations to them, but then you start getting into areas where temp tables might be better), so they're not always as easy to deal with. That said, a programming method should not be chosen just because it is easier, especially in SQL.Wed, 09 Dec 2009 07:49:32 GMTGaradinhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxnot sure what ur saying about the selecting for a cte because u can sdo that w/ the #tables as well.However that is very interesting the the QO will look at a @table w/ n records and take it as having 1 record. That explains some search optimization i was doing years ago that wouldn't play nice.Wed, 09 Dec 2009 07:41:27 GMTBaldingLoopManhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]BaldingLoopMan (12/9/2009)[/b][hr]All very useful info guys. Once again it appears the geniuses at sql server have designed a new way to do the same thing but w/ different syntax. Sure there are some minor performance gains as usual. Sorry for the disgruntled attitude. The gators lost, I just got in, and haven’t finished my coffee. Also I just ate about 2 lbs of bacon at an all u can eat breakfast buffet. Bacon is my weakness and I’m paying for it now.Personally i develop using the #tables then convert them to @tables where needed when moving my code to prod. I like the #tables in development because i can see what is in them after the process runs and so on. It's essential to the dev process.Perhaps i will start to integrate these CTE's going forward and be a good boy.[/quote]You can see what is in a CTE as well, just SELECT * from it. I'm actually intending to write an article on temp tables and how they're not evil... but they're not always applicable either. Derived tables / CTE's can provide a marked performance increase over temp tables / table variables *in some cases*. Every situation is different, and CTE's (or derived tables) definitely have their place.Wed, 09 Dec 2009 07:28:37 GMTGaradinhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]BaldingLoopMan (12/9/2009)[/b][hr]Are u saying if i'm using a #table and it has 10,000 recs then the optimizer may not optimize properly? Interesting. Would it by using the CTE w/ 10,000 recs?[/quote]No, #tables have statistics so the QO will know that the table has 10,000 records. An @table with 10,000 records, however, will be treated by the QO as if it had only 1 row. This may result in a less than optimal execution plan for the query.Wed, 09 Dec 2009 07:28:14 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxAre u saying if i'm using a #table and it has 10,000 recs then the optimizer may not optimize properly? Interesting. Would it by using the CTE w/ 10,000 recs?Wed, 09 Dec 2009 07:23:22 GMTBaldingLoopManhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]BaldingLoopMan (12/9/2009)[/b][hr]All very useful info guys. Once again it appears the geniuses at sql server have designed a new way to do the same thing but w/ different syntax. Sure there are some minor performance gains as usual. Sorry for the disgruntled attitude. The gators lost, I just got in, and haven’t finished my coffee. Also I just ate about 2 lbs of bacon at an all u can eat breakfast buffet. Bacon is my weakness and I’m paying for it now.Personally i develop using the #tables then convert them to @tables where needed when moving my code to prod. I like the #tables in development because i can see what is in them after the process runs and so on. It's essential to the dev process.Perhaps i will start to integrate these CTE's going forward and be a good boy.[/quote]Be careful using table variables. Since they do not have statistics, the Query Optimizer assumes that table variables always have 1 row regardless of actual number of rows. For a table variable with a few hundred rows, not bad, but when you get to thousands and more you won't get an optimal execution plan for the query.Wed, 09 Dec 2009 07:17:59 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxAll very useful info guys. Once again it appears the geniuses at sql server have designed a new way to do the same thing but w/ different syntax. Sure there are some minor performance gains as usual. Sorry for the disgruntled attitude. The gators lost, I just got in, and haven’t finished my coffee. Also I just ate about 2 lbs of bacon at an all u can eat breakfast buffet. Bacon is my weakness and I’m paying for it now.Personally i develop using the #tables then convert them to @tables where needed when moving my code to prod. I like the #tables in development because i can see what is in them after the process runs and so on. It's essential to the dev process.Perhaps i will start to integrate these CTE's going forward and be a good boy.Wed, 09 Dec 2009 07:13:05 GMTBaldingLoopManhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]niall.baird (12/8/2009)[/b][hr]I *can* read Garadin. That is why I was questioning the above statement. Seems to me that defining a #table would be more use, as you can use it in more places - unless of course, I am missing something.[/quote]heh, I couldn't resist. ;-)Seriously though, don't take Lynn's word for it, run up a quick test and see for yourself. They see a ton of usage even with their limitations. They *can* also incur less overhead than creating a temp table, depending on your usage.Tue, 08 Dec 2009 20:52:16 GMTGaradinhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxThat makes a bit more sense - thanks for explaining, LynnTue, 08 Dec 2009 19:31:44 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxIn SQL Server 2000, at a previous employer, I wrote several queries that used the same derived table several times in a single select statement. It was a royal pain to write, and when the derived table had to be modified it had to be modified in several places. Enter SQL Server 2005 and CTE's. Now, just before the select statement, I can define to "derived table" once and use it several times, just like a table in the select statement. If the CTE needs to be modified, one place to make the change.CTE's are very useful when used properly. Sometimes a temporary table is a better option in a stored proc.Tue, 08 Dec 2009 19:29:47 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxI *can* read Garadin. That is why I was questioning the above statement. Seems to me that defining a #table would be more use, as you can use it in more places - unless of course, I am missing something.Tue, 08 Dec 2009 19:07:18 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]niall.baird (12/8/2009)[/b][hr]Seriously? You can only use a CTE in the statement immediately following?When I read the article, the impression I got was that you could define a CTE at the top of something like a stored proc, then use it all the way through. Is my understanding wrong?[/quote][quote][b]Lynn Pettis(12/8/2009)[/b][hr]They can only be referenced by the immediately following SELECT/INSERT/UPDATE/DELETE statement.[/quote]Tue, 08 Dec 2009 19:02:53 GMTGaradinhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxSeriously? You can only use a CTE in the statement immediately following?When I read the article, the impression I got was that you could define a CTE at the top of something like a stored proc, then use it all the way through. Is my understanding wrong?Tue, 08 Dec 2009 18:22:59 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxIf you haven't already, you may also want to read this [url=http://www.sqlservercentral.com/articles/T-SQL/68651/][b]article[/b][/url].Tue, 08 Dec 2009 16:34:40 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspx[quote][b]BaldingLoopMan (12/8/2009)[/b][hr]so for example. I have the below. Is this the same basic principle as using an into #tablename and then querrying it? Are the CTE's specific to the runtime of a stored procedure or once their defined thay can be refferenced forever? WITH EmployeeSubordinatesReport (EmployeeID, LastName, FirstName, NumberOfSubordinates, ReportsTo) AS( SELECT EmployeeID, LastName, FirstName, (SELECT COUNT(1) FROM Employees e2 WHERE e2.ReportsTo = e.EmployeeID) as NumberOfSubordinates, ReportsTo FROM Employees e)SELECT LastName, FirstName, NumberOfSubordinatesFROM EmployeeSubordinatesReport[/quote]They can only be referenced by the immediately following SELECT/INSERT/UPDATE/DELETE statement. Think of them more as a derived table.Tue, 08 Dec 2009 16:13:57 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic831093-338-1.aspxso for example. I have the below. Is this the same basic principle as using an into #tablename and then querrying it? Are the CTE's specific to the runtime of a stored procedure or once their defined thay can be refferenced forever? WITH EmployeeSubordinatesReport (EmployeeID, LastName, FirstName, NumberOfSubordinates, ReportsTo) AS( SELECT EmployeeID, LastName, FirstName, (SELECT COUNT(1) FROM Employees e2 WHERE e2.ReportsTo = e.EmployeeID) as NumberOfSubordinates, ReportsTo FROM Employees e)SELECT LastName, FirstName, NumberOfSubordinatesFROM EmployeeSubordinatesReportTue, 08 Dec 2009 15:57:01 GMTBaldingLoopMan