CTEs (common table expressions) are persisted temporary data sets, that allow you to store a single query to go back to later in your script. They’re underrated compared to the subquery, that seems to be what most analysts around me use. Here’s why I prefer to use CTEs when building SQL queries.
In the example below I’ve used a CTE to:
Where you see a WITH, is the CTE starting and then I’m naming them ‘delivered’ and ‘unsubs’ before starting to tell the CTE what I want to return:
When I do the final ‘join everything together’ part I’m joining fields from the ‘delivered’ dataset such as ‘delivered.email’.
Here is an example of a Subquery. I don’t use them often because my brain doesn’t work that way. I would rather get all my datasets separately then join them all together.
The way I get my head around reading it is thinking about it from the inside out. It’s nesting everything you need together, but in my opinion, it tends to get ugly really quickly.
You can use them multiple times throughout your script and they are readable, you can return what you need then reference it later.
If you don’t have write permissions this may not be possible and if it’s only used for this query your DBA might not be thrilled with you creating one-off tables.
CTEs don’t last forever and can only be used in the query you’re currently in, unlike temp tables or views that can survive outside the current script.
SQL server will always decide for you, via the query planner, the best way to execute your query. If you ask your friendly DBA which strategy to use, they will tell you ‘it depends’ because it does. The CTE is all about readability, so if it works for you give it a try.
Which do you prefer? The CTE, subquery or just creating a table?
Originally published at dev.to.