{"id":97060,"date":"2023-06-26T19:12:19","date_gmt":"2023-06-26T19:12:19","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=97060"},"modified":"2026-03-17T19:46:43","modified_gmt":"2026-03-17T19:46:43","slug":"using-a-subquery-in-a-select-statement","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/t-sql-programming-sql-server\/using-a-subquery-in-a-select-statement\/","title":{"rendered":"SQL Subquery in SELECT: Examples & Syntax Guide"},"content":{"rendered":"

A subquery in SQL is a SELECT statement embedded inside another SQL statement – typically within a WHERE, FROM, or SELECT clause. SQL Server supports two types: basic (standalone) subqueries that execute independently, and correlated subqueries that reference columns from the outer query.<\/p>\n

Use subqueries in WHERE with comparison operators or IN\/EXISTS for filtering, in FROM as derived tables for intermediate result sets, or in SELECT for computed column values. This guide covers both types with working examples against the AdventureWorks database.<\/p>\n

This article is part of Greg Larsen's continuing series on Learning T-SQL. To see all the items in the series, click here<\/a>.<\/strong><\/p>\n<\/p>\n

Did you know you can include a SELECT<\/code> statement within another SELECT<\/code> statement? When a SELECT<\/code> statement is embedded within another statement it is known as a subquery. There are two types of subqueries: basic subquery and correlated subquery.<\/p>\n

In this article I will be discussing both types of subqueries and will be providing examples of how to use a subquery in different places within in a SELECT<\/code> statement.<\/p>\n

Difference between a basic subquery and a correlated subquery<\/h2>\n

A basic subquery is a \u201cstand alone\u201d SELECT<\/code> statement that is embedded inside another SQL statement. By \u201cstand alone\u201d, I mean the SELECT<\/code> statement that is embedded in another statement can be run independently from the statement in which it is embedded. A correlated subquery on the other hand is also a SELECT<\/code> statement embedded within another query that has a dependence on the statement in which it is embedded. The correlated subquery cannot be run independently from the statement it is embedded because of the dependency.<\/p>\n

A subquery and correlated subquery can be used anywhere in a SQL command that an expression can be used. Both types of subqueries are also known as an \u201cinner query\u201d or \u201cinner select\u201d. Whereas the SQL statement that contains the embedded subquery is known as the outer query. Subqueries are easy to spot because they are contained within a set of parentheses.<\/p>\n

Depending on how the inner query is used in relationship to the outer query, will determine how many columns and values a subquery can return. For example, when a subquery is used in a WHERE<\/code> cause that contains a comparison operator (=<\/code>, !=<\/code>, <<\/code>, ><\/code>, or >=<\/code>) the subquery needs to return a single column value.<\/p>\n

If the subquery is used with a comparison operator that supports multiple values, like an IN<\/code> expression, then the subquery can return multiple values. A subquery can also return multiple columns when used in an EXISTS<\/code> expression or when used in a derived table in the FROM<\/code> clause.<\/p>\n

To better understand how to use these two different types of subqueries in a SELECT<\/code> statement let me go through a few subquery examples in the following sections.<\/p>\n

Read also:\u00a0
<\/strong>Gaps and islands analysis in SQL<\/a>
<\/strong>CHOOSE function in SQL Server<\/a><\/p>\n

Test data<\/h2>\n

All the examples in this article will run against that AdventureWorks2019 OLTP <\/em>sample database. If you want to follow along and run the examples in this article you will need to download and restore the backup file for AdventureWorks2019 <\/em>databases. The download link for this backup can be found on this web page<\/a>, or by downloading using this link<\/a>.<\/p>\n

Ways to use subqueries<\/h2>\n

In the following sections, I will demonstrate several ways to use a subquery to create richer queries that I have demonstrated before. Subqueries let you have dynamic, data-driven queries where instead of a literal value (or list of values), you can dynamically get a value or list of values from a query.<\/p>\n

Using a subquery in a column list<\/h3>\n

Both types of subqueries can be used in a column list. When a basic or correlated subquery is used in a column list it can only return a single value. The value returned will be incorporated into the result set as a column value in the outer query. To see basic subquery in a column list in action consider the code in Listing 1.<\/p>\n

SELECT TerritoryID FROM Sales.Customer\n        WHERE CustomerID = 29974;<\/pre>\n
Listing 1: Code to return a TerritoryID <\/em> <\/strong><\/p>\n
The code in Listing 1 will return a TerritoryID<\/code> for CustomerID = 29964<\/code>. This query will be used as a subquery in Listing 2.<\/p>\n
USE AdventureWorks2019; \nGO \nSELECT CustomerID,\n       DueDate,        \n       TotalDue,        \n       (SELECT TerritoryID \n        FROM Sales.Customer         \n        WHERE CustomerID = 29974) AS TerritoryID \nFROM Sales.SalesOrderHeader \nWHERE CustomerID = 29974;<\/pre>\n
Listing 2: Using a subquery in a column list<\/strong><\/p>\n
By Reviewing the code in Listing 2 you can see the code from Listing 1 is embedded in the column list. In Listing 2 the first three column values CustomerID<\/code>, <\/em>DueDate<\/code> and <\/em>TotalDue<\/code> are returned from the Sales.SalesOrderHeader<\/code> table. But the 4th<\/sup> column returned is from the results of the subquery. Or in this case the TerritoryID<\/code> from the Sales.Customer<\/code> table.<\/p>\n
When the code in Listing 2 is executed the results in Report 1 are produced.<\/p>\n
<\/p>\n
Report 1: Results when Listing 2 is run<\/strong><\/p>\n
The subquery that returns the TerritoryID<\/code> column value is only evaluated one time, and the values returned from the subquery are then placed on every row returned from the outer query. Additionally worth mentioning is the basic subquery code can be run independently of the code in which it is embedded. Since this code can be run independently it make this embedded SELECT<\/code> statement a basic subquery, and not a correlated subquery.<\/p>\n
A correlated subquery can also be included in a column list. To demonstrate this, refer to Listing 3.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT TOP 5 C.CustomerID, \n       (SELECT SUM(TotalDue) FROM Sales.SalesOrderHeader H\n        WHERE H.CustomerID = C.CustomerID) AS TotalDue\nFROM Sales.Customer C\nORDER BY TotalDue DESC;<\/pre>\n
Listing 3: Correlated subquery in selection list<\/strong><\/p>\n
When the code is Listing 3 is executed the results in Report 2 is displayed.<\/p>\n
<\/p>\n
Report 2: Results when Listing 3 is run <\/strong><\/p>\n
The difference between a basic subquery and a correlated subquery is the correlate subquery references columns from the outer query. In Listing 3 the correlated subquery referenced the column C.CustomerID<\/code>. The correlated subquery is run once for every row returned from the outer query. The correlated subquery calculates the total amount due for each customer selected. Another difference between a basic query and a correlated subquery is the correlated subquery cannot be run independently of the outer query without getting an error.<\/p>\n
When a subquery or correlated subquery is used in the column list the embedded code can only bring back a single column and a single column value. If you try to return multiple columns, or multiple values an error will occur.<\/p>\n
To show what will happen when multiple columns are requested in a subquery within a column list, I will run the code in Listing 4.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT CustomerID,\n       DueDate,\n       TotalDue,\n       (SELECT TerritoryID, StoreID FROM Sales.Customer\n        WHERE CustomerID = 29974) AS TerritoryID\nFROM Sales.SalesOrderHeader\nWHERE CustomerID = 29974;<\/pre>\n
Listing 4: Trying to bring back multiple column values in subquery code <\/strong><\/p>\n
In the subquery in Listing 4, the StoreID<\/code> column was added to the subquery. When this code is executed the error in Report 3 is produced.<\/p>\n
Msg 116, Level 16, State 1, Line 7<\/code>
Only one expression can be specified in the select list when the subquery is not introduced with EXISTS.<\/code><\/p>\n
Report 3: Error when more than one column is identified in a column list subquery. <\/strong><\/p>\n
In order to bring back the StoreID<\/code> value a second subquery can be added to the original code, as was done in Listing 5.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT CustomerID,\n       DueDate,\n       TotalDue,\n       (SELECT TerritoryID FROM Sales.Customer\n        WHERE CustomerID = 29974) AS TerritoryID,\n       (SELECT StoreID FROM Sales.Customer\n        WHERE CustomerID = 29974) AS StoreID\nFROM Sales.SalesOrderHeader\nWHERE CustomerID = 29974;<\/pre>\n
Listing 5: Having multiple subqueries in a column list.<\/strong><\/p>\n
I\u2019ll leave it up to you to verify that both the TerritoryID<\/code> and StoreID<\/code> values are returned using the two different subqueries in Listing 5.<\/p>\n
Using a Subquery in a WHERE clause<\/h3>\n
A basic and correlated subquery can also be used in a WHERE<\/code> statement. Depending on the operators used in the WHERE<\/code> constraint will determine the number of values a subquery can return. If the subquery uses one of these operators: “=<\/code>, !=<\/code>, <<\/code>, ><\/code>, or >=\"<\/code> then only a single value can be returned from the subquery in the WHERE<\/code> constraint. To show an example of using a basic subquery in the WHERE<\/code> constraint that uses one of these operators review the code in Listing 6.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT TOP 5 CustomerID, TerritoryID, TotalDue \nFROM  Sales.SalesOrderHeader\nWHERE TerritoryID = (SELECT TerritoryID \n                     FROM Sales.SalesTerritory \n                     WHERE Name = 'Northeast');<\/pre>\n
Listing 6: Using a subquery in the WHERE constraint. <\/strong><\/p>\n
In Listing 6 the subquery code is associated with the WHERE<\/code> constraint. In this case the subquery returns the TerritoryID<\/code> for the \u201cNortheast\u201d region. The TerritoryID<\/code> returned is then used in conjunction the equals (\u201c=<\/code>\u201d) operator. When the code in Listing 6 is executed, it produces the output in Report 4.<\/p>\n
<\/p>\n
Report 4: Output when Listing 5 is executed.<\/strong><\/p>\n
The operator used in the WHERE<\/code> constraint in the prior example can return a single value because the operator \u201c=<\/code>\u201d was used. But when an operator used in conjunction with the subquery can handle multiple values, then a subquery can bring back more than a single value. To show how multiple values can be used in a correlated subquery the \u201cIN\u201d operator will be used in the subquery in Listing 6.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT TOP 5 CustomerID, TerritoryID, TotalDue \nFROM Sales.SalesOrderHeader\nWHERE TerritoryID IN (SELECT TerritoryID \n                     FROM Sales.SalesTerritory \n                     WHERE Name Like '%east');<\/pre>\n
Listing 6: Using a correlated subquery with the IN operator<\/strong><\/p>\n
The subquery in listing 6 returns multiple TerritoryID<\/em> values. Multiple values can be returned because the IN operator supports multiple values. When the code in Listing 6 is executed the results in Report 4 is produced.<\/p>\n
<\/p>\n
Report 4: Output produced when the in operator is used.<\/strong><\/p>\n
Here you can see TerritoryID<\/code> values of 2 and 5 were returned from the subquery, but since it is not a correlated subquery, you can also simply execute the code in the IN<\/code> expression, something I frequently do by just highlighting the code in SSMS:<\/p>\n
\"A 
The output of this code will be the TerritoryID<\/code> values, which are, as expected, 2 and 5.<\/p>\n
Using a Subquery in a FROM clause<\/h3>\n
A subquery can also be used in a FROM<\/code> clause. When a subquery is used in a FROM<\/code> clause the set created by the subquery is commonly called a derived<\/strong> table, which is stored in memory. In Listing 7 I have used a subquery to return a subset of the SalesOrderHeader<\/code> rows for a specific date. The derived table is then joined with the SalesOrderDetail<\/code>, <\/em>and the Production.Product<\/code> table to build the final result set.<\/p>\n
USE AdventureWorks2019;\nGO \nSELECT Header.SalesOrderID, \n       Header.OrderDate,  \n       Name, \n       StandardCost \nFROM \n   (SELECT SalesOrderID, \n           OrderDate\n    FROM Sales.SalesOrderHeader \n    WHERE OrderDate = '2012-08-21 00:00:00.000') AS Header\n     JOIN Sales.SalesOrderDetail AS Detail\n       ON Header.SalesOrderID = Detail.SalesOrderID\n     JOIN Production.Product AS Product\n       ON Detail.ProductID = Product.ProductID;<\/pre>\n
Listing 7: Subquery in the FROM clause<\/strong><\/p>\n
When the SELECT<\/code> statement in Listing 7 is execute the results in Report 5 are produced.<\/p>\n
<\/p>\n
Report 5: Results when Listing 7 is executed.<\/strong><\/p>\n
The SalesOrderID<\/code> and OrderDate<\/code> are the columns that came from the subquery. Writing a subquery that is used in a FROM<\/code> clause should be avoid if there is another way to write the query. This is because there are no indexes on a derived table so performance might suffer.<\/p>\n
A correlated subquery cannot be used in a FROM<\/code> clause. The reason is because the correlated subquery cannot be evaluated for every row of the outer query.<\/p>\n
Using a Subquery in a HAVING clause<\/h3>\n
A subquery can also be used in a HAVING<\/code> clause. To show how a subquery can be used in a HAVING<\/code> clause let\u2019s first consider the SELECT<\/code> statement in Listing 8.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT COUNT(*) AS NumOfOrders\n        FROM [Sales].[SalesOrderHeader]\n        WHERE OrderDate = '2014-05-01 00:00:00.000';<\/pre>\n
Listing 8: Number of orders created for a specific date<\/strong><\/p>\n
The SELECT<\/code> statement in Listing 8 identifies the orders that were created on May 1, 2014, which in this case where 227 orders created on that date. Suppose now you want to identify which OrderDates<\/code> have more orders than the number of orders created on May 1, 2014 (which is 227). To do that you could take the query in Listing 8 and place it in the HAVING<\/code> clause as a subquery, as I have done in Listing 9.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT COUNT(*) AS NumOfOrders, OrderDate \nFROM [Sales].[SalesOrderHeader]\nGROUP BY OrderDate\nHAVING COUNT(*) >\n       (SELECT COUNT(*) AS NumOfOrders\n        FROM [Sales].[SalesOrderHeader]\n        WHERE OrderDate = '2014-05-01 00:00:00.000')\nORDER BY OrderDate;<\/pre>\n
Listing 9: Using a subquery in a HAVING clause<\/strong><\/p>\n
When Listing 9 is run the results are shown in Report 6<\/p>\n
<\/p>\n
Report 6: Results when Listing 9 is executed.<\/strong><\/p>\n
By reviewing Report 6 you can see that there are 6 OrderDate <\/code>values that have processed more orders than on May 1, 2014.<\/p>\n
A correlated subquery can also be used in a HAVING<\/code> clause. To demonstrate this, suppose you want to return the SalesOrderID<\/code> values in the Sales.SalesOrderHeader<\/code> table that have more than 70 detailed records. The code in Listing 10 accomplishes this by using a correlated subquery in the HAVING<\/code> clause.<\/p>\n
USE AdventureWorks2019\nGO\nSELECT H.SalesOrderID \nFROM Sales.SalesOrderHeader AS H\nGROUP BY SalesOrderID\n-- Having more that 70 detail rows\nHAVING (SELECT COUNT(*) \n        FROM Sales.SalesOrderDetail AS D\n        WHERE H.SalesOrderID = D.SalesOrderID) > 70;<\/pre>\n
Listing 10: Correlated subquery in HAVING clause.<\/strong><\/p>\n
When the code in Listing 10 is run the four rows in Report 7 were found.<\/p>\n
<\/p>\n
Report 7: The results when the code in Listing 10 is executed. <\/strong><\/p>\n
Using a subquery in a Function call<\/h3>\n
A subquery can also be used as a parameter of a function call. The code in Listing 11 shows how a subquery can be used as a parameter to the DATEDIFF<\/code> function.<\/p>\n
USE AdventureWorks2019;\nGO\nSELECT TOP 3 SalesOrderID,\n             CustomerID,\n             OrderDate,\n             DATEDIFF\n               (dd,\n                OrderDate, \n                (SELECT Max(OrderDate) \n                 FROM Sales.SalesOrderHeader \n                 WHERE CustomerID = 29610)\n                ) NumOfDays\nFROM Sales.SalesOrderHeader\nWHERE CustomerID = 29610;<\/pre>\n
Listing 11: Using a subquery in a function call<\/strong><\/p>\n
In Listing 11 the subquery determines the maximum order date for CustomerID = 29610<\/code>. Which in this case is 2013-02-08. The DATEDIFF<\/code> function then determines the number of days between that date and other orders for CustomerID<\/code> 29610, and only returns the TOP<\/code> three orders. When the code in Listing 11 is executed, the results are shown in Report 8.<\/p>\n
<\/p>\n
Report 8: Results when Listing 10 is executed<\/strong><\/p>\n
Which in this case are the oldest three orders for CustomerID<\/code> 29610.<\/p>\n
Performance Considerations for Basic Subqueries<\/h2>\n
In the Microsoft documentation about subqueries found here<\/a>, the following statement regarding performance is mentioned:<\/p>\n
In Transact-SQL, there’s usually no performance difference between a statement that includes a subquery and a semantically equivalent version that doesn’t<\/em>.<\/p>\n
To validate that a subquery performs the same as an equivalent version that doesn\u2019t use a subquery let\u2019s review the code in Listing 12.<\/p>\n
USE AdventureWorks2019;\nGO\n-- Subqeury\nSELECT OD.*  FROM Sales.SalesOrderDetail AS OD\nWHERE ProductID = (SELECT ProductID \n                   FROM Production.Product\n                WHERE Name = 'AWC Logo Cap'); \nGO\n-- Join query \nSELECT OD.*\nFROM Sales.SalesOrderDetail AS OD\nINNER JOIN \nProduction.Product AS P\nON OD.ProductID = P.ProductID\nWHERE P.Name = 'AWC Logo Cap';\nGO<\/pre>\n
Listing 12: Two different but similar SELECT queries<\/strong><\/p>\n
In Listing 12 there are two different SELECT<\/code> statements. The first SELECT<\/code> statement uses a subquery to identify which Sales.SalesOrderDetail<\/code> records to return. The second SELECT<\/code> query returns uses a JOIN<\/code> to identify the same set of Sales.SalesOrderDetail<\/code> records. Both queries are equivalent. Meaning they have the same execution plan and return the same set of records.<\/p>\n
Figure 1 show the actual execution plan for the first query, the SELECT<\/code> statement with the subquery. Whereas Figure 2 shows the execution plan for the SELECT<\/code> statement that uses the JOIN logic.<\/p>\n
<\/p>\n
Figure 1: Actual execution plan for SELECT statement that contains the subquery<\/strong><\/h1>\n
<\/p>\n
Figure 2: Actual execution plan for the SELECT statement<\/strong><\/p>\n
By reviewing both execution plans you can see that other than the text of the query, the plans are both exactly the same. It should be noted that as your queries grow more and more complex there is a breaking point where it is too costly to find the perfect plan.<\/p>\n
Performance Issues when using correlated subqueries<\/h1>\n
When using a correlated subquery you need to worry about the number of rows in the outer query. When the outer query contains a small number of rows a correlated subquery doesn\u2019t perform too bad. But as volume of rows in the outer query gets larger you will find a correlated subquery start to have performance issues.<\/p>\n
This is because the inner query (correlated subquery) has to be evaluated for every row in the outer query. Keep this scale issue in mind when you are testing out correlated subqueries. Make sure you test your code against production size tables prior to promoting a code with a correlated subquery to into your production environment.<\/p>\n
Keep in mind that as rowcounts increase, complexity can be a concern as well. For example, you can next subqueries many levels deeps such as:<\/p>\n
SELECT <Columns>\nFROM    Table1\nWHERE  ColumnName IN \n            (SELECT ColumnName\n             FROM    Table2\n             WHERE  EXISTS (SELECT *\n                            FROM Table3\n                            WHERE Name IN (\n                                   SELECT Name\n                                   FROM   Table4\u2026<\/pre>\n
This may be necessary to answer a question your users have, but at a certain point a query with too many subqueries can become complex to optimize and execute reasonably. In some cases, it may be useful to break your queries up and use temporary tables<\/a> to capture rows to eliminate some subqueries.<\/p>\n
Using a subquery in a SELECT statement<\/h1>\n
A subquery is a SELECT<\/code> statement that is embedded in another SQL statement. A subquery can be a stand-alone SELECT<\/code> statement (meaning it can be run independently of the outer query) or it can be a correlated SELECT<\/code> statement (meaning it cannot be run independently of the outer query).<\/p>\n
Depending on the operator in which a subquery or correlated subquery is used with, the subquery might only be allowed to return a single value or more than one value, and\/or column. Subquery performance is typically the same as an equivalent query that uses a JOIN<\/code>. In this article I only showed how to use subqueries in a SELECT<\/code> statement. but subqueries can also be used in other statements like INSERT<\/code>, UPDATE<\/code> and DELETE<\/code>.<\/p>\n\n\n
\n    
\n        
\n            
\n                
Fast, reliable and consistent SQL Server development…<\/h3>\n                
\n                                            …with SQL Toolbelt Essentials. 10 ingeniously simple tools for accelerating development, reducing risk, and standardizing workflows.                                    <\/div>\n            <\/div>\n                            Learn more & try for free<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
\n    
FAQs: How to use a subquery in a SELECT statement in SQL Server<\/h2>\n\n                        
1. What is the difference between a subquery and a correlated subquery?<\/h3>\n            
\n                
A basic subquery is a standalone SELECT that can execute independently of the outer query. A correlated subquery references one or more columns from the outer query, so it executes once for each row processed by the outer statement. Correlated subqueries are more flexible but can be slower on large datasets because of the row-by-row execution pattern.<\/p>\n            <\/div>\n                    
2. Can you use a subquery in a SELECT clause in SQL Server?<\/h3>\n            
\n                
Yes. A scalar subquery in the SELECT clause returns a single value for each row of the outer query. For example, SELECT ProductName, (SELECT AVG(Price) FROM Products) AS AvgPrice FROM Products computes the average alongside each row. The subquery must return exactly one column and one value, or SQL Server raises an error.<\/p>\n            <\/div>\n                    
3. When should you use EXISTS vs. IN with a subquery?<\/h3>\n            
\n                
Use EXISTS when you only need to check whether matching rows exist – it stops processing as soon as it finds the first match, making it faster for large datasets. Use IN when the subquery returns a small, distinct set of values to compare against. EXISTS handles NULLs more predictably than IN, which can produce unexpected results when the subquery contains NULL values.<\/p>\n            <\/div>\n            <\/section>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Learn how to use subqueries in SQL SELECT statements with practical examples. Covers basic subqueries, correlated subqueries, EXISTS, IN, and derived tables in SQL Server.…<\/p>\n","protected":false},"author":78478,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[53,143525,143531],"tags":[],"coauthors":[11330],"class_list":["post-97060","post","type-post","status-publish","format-standard","hentry","category-featured","category-learn","category-t-sql-programming-sql-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/97060","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/78478"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=97060"}],"version-history":[{"count":10,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/97060\/revisions"}],"predecessor-version":[{"id":109252,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/97060\/revisions\/109252"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=97060"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=97060"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=97060"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=97060"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}