{"id":1760,"date":"2014-02-12T00:00:00","date_gmt":"2014-02-12T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/sql-server-indexed-views-the-basics\/"},"modified":"2026-04-16T09:53:15","modified_gmt":"2026-04-16T09:53:15","slug":"sql-server-indexed-views-the-basics","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/learn\/sql-server-indexed-views-the-basics\/","title":{"rendered":"SQL Server Indexed Views: What They Are and How to Create Them"},"content":{"rendered":"
\n

An indexed view in SQL Server is a view with a unique clustered index physically built on it – persisting the view’s result set on disk rather than recomputing it on every query. This makes complex aggregations and multi-table joins significantly faster when the same view is queried frequently, at the cost of additional storage and write overhead. SQL Server’s indexed views are equivalent to what other databases call materialised views. <\/strong><\/p>\n

Creating an indexed view requires two conditions: the view must be created WITH SCHEMABINDING (locking the underlying table schema), and a unique clustered index must be created on the view. In Enterprise Edition, the query optimiser automatically considers indexed views to satisfy queries; in Standard Edition, you must use the NOEXPAND hint explicitly.<\/strong><\/p>\n

SQL Server views are helpful in many ways, for example in encapsulating complex multi-table query logic, allowing us to simplify client code. Views make queries faster to write, but they don’t improve the underlying query performance. However, we can add a unique, clustered index to a view, creating an indexed view, and realize potential and sometimes significant performance benefits, especially when performing complex aggregations and other calculations. In short, if an indexed view can satisfy a query, then under certain circumstances, this can drastically reduce the amount of work that SQL Server needs to do to return the required data, and so improve query performance.<\/p>\n

Indexed views can be a powerful tool, but they are not a ‘free lunch’ and we need to use them with care. Once we create an indexed view, every time we modify data in the underlying tables then not only must SQL Server maintain the index entries on those tables, but also the index entries on the view. This can affect write performance. In addition, they also have the potential to cause other issues. For example, if one or more of the base tables is subject to frequent updates, then, depending on the aggregations we perform in the indexed view, it is possible that we will increase lock contention on the view’s index.<\/p>\n

This article will start from the basics of creating indexed views, and the underlying requirements in order to do so, and then discuss their advantages and the situations in which they can offer a significant boost to query performance. We’ll also consider the potential pitfalls of which you need to be aware before deciding to implement an indexed view.<\/p>\n

From Views to Indexed Views<\/h1>\n

Nobody sets out to write overly complex queries. Unfortunately, however, applications grow more complex as the users demand new features, and so the accompanying queries grow more complex also. We don’t always have time to rewrite a query completely, or may not even know a better way to write it.<\/p>\n

Standard SQL Server views can help. When we encapsulate complex multi-table query logic in a view, any application that needs that data is then able to issue a much simpler query against the view, rather than a complex multi-JOIN<\/code> query against the underlying tables. Views bring other advantages too. We can grant users SELECT<\/code> permissions on the view, rather than the underlying tables, and use the view to restrict the columns and rows that are accessible to the user. We can use views to aggregate data in a meaningful way.<\/p>\n

Let’s say we need to run various queries against the AdventureWorks2012<\/code> database to return information regarding items that customers have purchased. The query in Listing 1 joins five tables to get information such as the client name, the order number and date, the products and quantities ordered.<\/p>\n

SELECT  CUST.CustomerID ,\n        PER.FirstName ,\n        PER.LastName ,\n        SOH.SalesOrderID ,\n        SOH.OrderDate ,\n        SOH.[Status] ,\n        SOD.ProductID ,\n        PROD.Name ,\n        SOD.OrderQty\nFROM    Sales.SalesOrderHeader SOH\n        INNER JOIN Sales.SalesOrderDetail SOD \n               ON SOH.SalesOrderID = SOD.SalesOrderID\n        INNER JOIN Production.Product PROD\n               ON PROD.ProductID = SOD.ProductID\n        INNER JOIN Sales.Customer CUST\n               ON SOH.CustomerID = CUST.CustomerID\n        INNER JOIN Person.Person PER\n               ON PER.BusinessEntityID = CUST.PersonID;\n\n<\/pre>\n
Listing 1<\/p>\n
Notice that we use two-part naming for all tables. Not only is this a good practice, it’s also a requirement when creating an indexed view (we’ll discuss further requirements as we progress). Let’s assume that many applications need to run queries like this, joining the same tables, and referencing the same columns in various combinations. To make it easier for our application to consume this data, we can create a view<\/p>\n
Create a View<\/h3>\n
Listing 2 creates a view based on our query definition, as shown in Listing 2.<\/p>\n
CREATE VIEW Sales.vCustomerOrders\nWITH SCHEMABINDING\nAS\n  <Select Statmenet from Listing 1><\/pre>\n
Listing 2<\/p>\n
Note that the WITH SCHEMABINDING<\/code> option is included here and is a requirement for creating an index on the view, which we’ll want to do shortly. This option stipulates that we cannot delete any of the base tables for the view, or ALTER<\/code> any of the columns in those tables. In order to make one of these changes, we would have to drop the view, change the table, and then recreate the view (and any indexes on the view).<\/p>\n
Now, each application simply has to run a much simpler query referencing the view, as shown in Listing 3.<\/p>\n
SELECT  CustomerID ,\n        FirstName ,\n        LastName ,\n        SalesOrderID ,\n        OrderDate ,\n        Status ,\n        ProductID ,\n        Name ,\n        OrderQty\nFROM    Sales.vCustomerOrders CO; \n<\/pre>\n
Listing 3<\/p>\n
However, when looking at the execution plan (Figure 1) we can see that SQL Server still performs index scans against each of the five underlying tables.<\/p>\n
\"1938-1-f5ac13b3-4c98-42d7-a553-c8524405e\"<\/p>\n
Figure 1<\/p>\n
Likewise, the STATISTICS IO<\/code> output (Figure 2) shows that SQL Server performed 2,172 logical reads against the five base tables.<\/p>\n
\"1938-4%20-%20query%20view%20statsio-7dcc\"<\/p>\n
Figure 2<\/p>\n
The execution plan reports the query cost as 6.01323, as shown in Figure 3.<\/p>\n
\"1938-3b%20-%20query%20view%20cost-d74f3b\"<\/p>\n
Figure 3<\/p>\n
We see the exact same execution plan, STATISTICS IO<\/code> output, and query cost if we run the query in Listing 1 again.<\/p>\n
Although the use of the view made writing the query easier, it had no impact on query performance. A simple view is just a virtual table, generated from a saved query. It does not have its own physical page structure to use, so it reads the pages of its underlying tables. In other words, when we query a simple view, the optimizer still has to access all of the underlying tables and perform the necessary JOIN<\/code>s and aggregations. It derives cardinality estimations, and hence the query plan, from statistics associated with those tables.<\/p>\n
Let’s see what happens, however, if we turn our standard view into an indexed view.<\/p>\n
Create a Unique, Clustered Index<\/h3>\n
Before we start, I should mention that there are a host of requirements attached to the creation of indexed views, in any SQL Server Edition. We’ll discuss these in more detail in the Index<\/em>ed<\/em> View Requirements<\/em> section, but if you have trouble creating an index on a view, it’s likely you’re breaking one of the rules.<\/p>\n
In order to turn our normal Sales.vCustomerOrders<\/code> view into an indexed view, we need to add a unique clustered index, as shown in Listing 4.<\/p>\n
CREATE UNIQUE CLUSTERED INDEX CIX_vCustomerOrders \n\tON Sales.vCustomerOrders(CustomerID, SalesOrderID, ProductID);\n<\/pre>\n
Listing 4<\/p>\n
When we add a unique clustered index to a view, we ‘materialize’ it. In other words, the ‘virtual table’ persists to disk, with its own page structure, and we can treat it just like a normal table. Any aggregations defined by the indexed view are now pre-computed, and any joins pre-joined, so the engine no longer has to do this work at execution time. SQL Server creates statistics for the indexed view, different from those of the underlying tables, to optimize cardinality estimations.<\/p>\n
A well-crafted indexed view can write fewer pages to disk than the underlying tables, meaning fewer pages queries need to read fewer pages to return results. This means faster, more efficient queries. Use the techniques and tips in this article to ensure your views are optimal!<\/p>\n
Let’s see the impact of our indexed view on query performance. These examples assume you’re running SQL Server Enterprise Edition<\/strong>, which will automatically consider indexes on a view when creating a query execution plan, whereas SQL Server Standard Edition won’t; you’ll need to use the WITH (NOEXPAND)<\/code> table hint directly in the FROM<\/code> clause of any query you wish to use the view (more on this shortly).<\/p>\n
When we re-run the query from Listing 3, we get the same result set, but the execution plan, shown in Figure 4, looks very different. Rather than several index scans with joins, the optimizer now determines that the optimal way to satisfy the query is to scan the clustered index of our view.<\/p>\n
\"1938-5%20-%20query%20view%20exec%20plan-\"<\/p>\n
Figure 4<\/p>\n
The optimizer now reads all the pages required from one index, rather than five, and STATISTICS IO<\/code> output reveals that this results in a 27% reduction in the number of logical reads the engine must perform in order to return the data, from 2,172 to 1,590.<\/p>\n
\"1938-6%20-%20query%20view%20statsio-4b9b\"<\/p>\n
Figure 5<\/p>\n
The overall query cost falls to 1.30858, as seen in Figure 6.<\/p>\n
\"1938-7%20-%20query%20view%20cost-60fb50e\"<\/p>\n
Figure 6<\/p>\n
It’s not only queries that reference the view directly that will benefit in this way. Any query that the Optimizer determines the view could satisfy can use the indexed view rather than underlying tables, a process termed view matching<\/em>. Try re-running Listing 1, which references the base tables rather than our indexed view. The Optimizer determines that the view’s index is the optimal way to retrieve the data and the execution plan will be identical to that in Figure 4.<\/p>\n
In Listing 5, we access the same base tables but also perform some aggregations.<\/p>\n
SELECT  CUST.CustomerID ,\n        SOH.SalesOrderID ,\n        SOH.OrderDate ,\n        SOD.ProductID ,\n        PROD.Name ,\n        SUM(SOD.OrderQty) AS TotalSpent\nFROM    Sales.SalesOrderHeader SOH\n        INNER JOIN Sales.SalesOrderDetail SOD\n               ON SOH.SalesOrderID = SOD.SalesOrderID\n        INNER JOIN Production.Product PROD\n               ON PROD.ProductID = SOD.ProductID\n        INNER JOIN Sales.Customer CUST\n               ON SOH.CustomerID = CUST.CustomerID\n        INNER JOIN Person.Person PER\n               ON PER.BusinessEntityID = CUST.PersonID\nGROUP BY CUST.CustomerID ,\n        SOH.SalesOrderID ,\n        SOH.OrderDate ,\n        SOD.ProductID ,\n        PROD.Name; \n<\/pre>\n
Listing 5<\/p>\n
Here, the execution plan shows that the Optimizer chose to use the clustered index on the view, rather than indexes on the base tables.<\/p>\n
\"1938-8%20-%20query%20matching%20view-5f5\"<\/p>\n
Figure 7<\/p>\n
This execution plan shows a yellow exclamation point over the clustered index scan, which is warning us of “Columns with no statistics”. We’ll discuss this in more detail shortly.<\/p>\n
\"1938-1-98ce757e-71ba-42ab-b4f3-f91812469\"<\/p>\n
Figure 8<\/p>\n
Aggregating Data with Indexed Views<\/h3>\n
Indexed views can really come into their own when we have many applications that need to perform complex aggregations<\/em>, and other calculations, on the same set of base tables. Rather than force SQL Server to perform these aggregations and calculations every time, upon query execution, we can encapsulate them in an indexed view. This can significantly reduce the amount of IO SQL Server must perform to retrieve the necessary data, and CPU time required to perform the calculations, and so can provide tremendous performance boosts.<\/p>\n
Before we dive into another example, it’s worth mentioning again that, despite the potential performance benefits, caution is required when implementing an indexed view unless the base tables are relatively static. We’ll discuss this in more detail shortly.<\/p>\n
Consider the query in Listing 6.<\/p>\n
SELECT  CUST.CustomerID ,\n        SOH.SalesOrderID ,\n        SOD.ProductID ,\n        SUM(SOD.OrderQty) AS TotalOrderQty ,\n        SUM(LineTotal) AS TotalValue\nFROM    Sales.SalesOrderHeader SOH\n        INNER JOIN Sales.SalesOrderDetail SOD\n               ON SOH.SalesOrderID = SOD.SalesOrderID\n        INNER JOIN Production.Product PROD ON PROD.ProductID = SOD.ProductID\n        INNER JOIN Sales.Customer CUST ON SOH.CustomerID = CUST.CustomerID\n        INNER JOIN Person.Person PER ON PER.BusinessEntityID = CUST.PersonID\nGROUP BY CUST.CustomerID ,\n        SOH.SalesOrderID ,\n        SOD.ProductID; \n<\/pre>\n
Listing 6<\/p>\n
This query produces an execution plan with several index scans and joins, shown in Figure 9. It also requires aggregation. Its execution plan is similar in nature to the one we saw in Figure 4, but with additional operations and a higher cost, of 7.62038.<\/p>\n
\"1938-9%20-%20query%20with%20aggregation-\"<\/p>\n
Figure 9<\/p>\n
The logical reads are high as well, spanning several tables, as seen in Figure 10.<\/p>\n
(121317 row(s) affected)\nTable 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\nTable 'SalesOrderDetail'. Scan count 1, logical reads 1246, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\nTable 'SalesOrderHeader'. Scan count 1, logical reads 58, physical reads 1, read-ahead reads 63, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\nTable 'Customer'. Scan count 1, logical reads 123, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\nTable 'Person'. Scan count 1, logical reads 67, physical reads 1, read-ahead reads 65, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\nTable 'Product'. Scan count 1, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\n<\/pre>\n
Figure 10<\/p>\n
Listing 7 creates an indexed view, vSalesSummaryCustomerProduct<\/code>, to help reduce the cost of this and similar queries.<\/p>\n
CREATE VIEW Sales.vSalesSummaryCustomerProduct\nWITH SCHEMABINDING\nAS\n    SELECT  CUST.CustomerID ,\n            SOH.SalesOrderID ,\n            SOD.ProductID ,\n            SUM(SOD.OrderQty) AS TotalOrderQty ,\n            SUM(LineTotal) AS TotalValue ,\n            COUNT_BIG(*) AS CountLines\n    FROM    Sales.SalesOrderHeader SOH\n            INNER JOIN Sales.SalesOrderDetail SOD\n                   ON SOH.SalesOrderID = SOD.SalesOrderID\n            INNER JOIN Production.Product PROD\n                   ON PROD.ProductID = SOD.ProductID\n            INNER JOIN Sales.Customer CUST\n                   ON SOH.CustomerID = CUST.CustomerID\n            INNER JOIN Person.Person PER\n                   ON PER.BusinessEntityID = CUST.PersonID\n    GROUP BY CUST.CustomerID ,\n            SOH.SalesOrderID ,\n            SOD.ProductID; \nGO\nCREATE UNIQUE CLUSTERED INDEX CX_vSalesSummaryCustomerProduct\n  ON Sales.vSalesSummaryCustomerProduct(CustomerID, SalesOrderID, ProductID); \nGO\n<\/pre>\n
Listing 7<\/p>\n
Note the use of COUNT_ BIG( *)<\/code> in this view, a requirement for indexed views that have a GROUP BY<\/code>. It is there for the internal maintenance of indexed views – it maintains a count of the rows per group in the indexed view.<\/p>\n
Now we can return the same result set by running the simple query in Listing 8.<\/p>\n
SELECT  CustomerID ,\n        SalesOrderID ,\n        TotalOrderQty ,\n        TotalValue\nFROM    Sales.vSalesSummaryCustomerProduct; \n<\/pre>\n
Listing 8<\/p>\n
Figure 11 shows that we’ve reduced the query cost from 7.62038 to 0.694508. If we check the STATISTICS IO<\/code> output, we’ll also find a substantial reduction in the number logical reads, from 1,498 across five indexes to 758.<\/p>\n
\"1938-10%20-%20view%20aggregated-1400d952\"<\/p>\n
Figure 11<\/p>\n
Again, notice the yellow exclamation mark; hovering over the index scan icon reveals that it is a “Columns with no statistics” warning on the SalesOrderID<\/code> column, the second column in the clustered index key. We can see that SQL Server has created a statistics object for this clustered index, as shown in Figure 12.<\/p>\n
\"1938-1-744e48f0-8481-4e81-87b5-94ac60314\"<\/p>\n
Figure 12<\/p>\n
However, if we run the query using the WITH (NOEXPAND) <\/code>hint, as shown in Figure 14, we will no longer see the warning.<\/p>\n
SELECT    CustomerID ,\n          SalesOrderID ,\n          TotalOrderQty ,\n          TotalValue\nFROM      Sales.vSalesSummaryCustomerProduct WITH ( NOEXPAND );\n\n<\/pre>\n
Listing 9<\/p>\n
What is going on? The difference lies in when and how SQL Server creates automatic statistics, and when it uses them. Simply put, if we do not use the WITH (NOEXPAND)<\/code> hint when querying an indexed view, the query optimizer will not use statistics created on the indexed view and neither will it create or update statistics automatically (i.e. those statistics objects that begin with _WA_SYS<\/code>).<\/p>\n
Without automatically created or updated statistics, there can be a slight or even drastic difference between the numbers of rows the optimizer estimates a query will return, and the actual number of rows returned. Pay attention to statistics warnings if you see them!<\/p>\n
What is the lesson to be learned here? Using the WITH (NOEXPAND)<\/code> hint when writing queries that reference indexed views is the best way to ensure optimal query plans.<\/p>\n
For a more in-depth review of statistics, try Managing SQL Server Statistics<\/a>, by Erin Stellato. For a thorough review of indexed views and statistics, reference Paul White’s article Indexed Views and Statistics<\/a>.<\/p>\n
Wait, SQL Server didn’t use my index!<\/h3>\n
Unfortunately, there may still be occasions when the query optimizer decides not to use an indexed view, even though it seems that it could satisfy a query. In fact, SQL Server may refuse to use the clustered index (or any non-clustered indexes) on a view, even if we reference the view directly in the query.<\/p>\n
Let’s return to our vCustomerOrders<\/code> example. Let’s say we want to query the view for the total number of orders a customer has placed, along with the total value of those orders, and we want to search by CustomerID<\/code>.<\/p>\n
SELECT  CustomerID ,\n        COUNT(SalesOrderID) AS OrderCount ,\n        SUM(TotalValue) AS OrderValue\nFROM    Sales.vSalesSummaryCustomerProduct\nWHERE   CustomerID = 30103\nGROUP BY CustomerID; \n<\/pre>\n
Listing 10<\/p>\n
The execution plan, in Figure 13, shows that the plan references the underlying tables and ignores our view and its index. The query cost is .072399.<\/p>\n
\"1938-1-729fe531-3aab-4982-b7e6-78bdcafec\"<\/p>\n
Figure 13<\/p>\n
To make the query optimizer use the unique clustered index I created on vSalesSummaryCustomerProduct<\/code>, we can use the NOEXPAND<\/code> hint.<\/p>\n
SELECT    CustomerID ,\n          COUNT(SalesOrderID) AS OrderCount ,\n          SUM(TotalValue) AS OrderValue\nFROM      Sales.vSalesSummaryCustomerProduct WITH ( NOEXPAND )\nWHERE     CustomerID = 30103\nGROUP BY  CustomerID; \n<\/pre>\n
Listing 11<\/p>\n
Now, the execution plan shows a clustered index seek, as shown in Figure 14, and the query cost is .003522.<\/p>\n
\"1938-1-92d77272-36b0-4557-9868-249a04892\"<\/p>\n
Figure 14<\/p>\n
Adding Non-clustered Indexes to an Indexed View<\/h3>\n
Once we’ve created an indexed view we can then treat it in much the same way as a normal table. We can add non-clustered indexes to boost query performance. Once again, exercise care. SQL Server has to maintain every index we add to a view, every time someone updates one of the contributing base tables. Indexed views work better for relatively static base tables.<\/p>\n
Let’s say we want to query our Sales.vCustomerOrders<\/code> view by product name.<\/p>\n
DECLARE @ProductName VARCHAR(50) \nSET @ProductName = 'LL Mountain Frame - Black, 44'\n\nSELECT  CustomerID ,\n        SalesOrderID ,\n        OrderQty ,\n        Name\nFROM    Sales.vCustomerOrders\nWHERE   Name = @ProductName;\n<\/pre>\n
Listing 12<\/p>\n
We get a clustered index scan on the view and the query cost is 1.30858.<\/p>\n
\"1938-1-09a7841b-c248-44b1-a1c8-b026b1c3c\"<\/p>\n
Figure 15<\/p>\n
It’s great that SQL Server is using the clustered index on the view; but a scan isn’t what we want; a seek would be better. However, once the clustered index exists, we can easily add useful non-clustered indexes, just as we can for any normal table.<\/p>\n
CREATE NONCLUSTERED INDEX IX_vCustomerOrders_Name\n  ON Sales.vCustomerOrders(Name);\n<\/pre>\n
Listing 13<\/p>\n
When we run the query in Listing 12 again, the execution plan is as shown in Figure 16. The query cost has gone down, to 1.27252.<\/p>\n
\"1938-1-24305b30-d1e7-4e3e-91bb-7b0e63d8c\"<\/p>\n
Figure 16<\/p>\n
This time the optimizer chose a seek operation on the new non-clustered index, which is what we wanted. However, it also needed to perform a key lookup to return the additional columns contained in the SELECT<\/code> clause but not included in the non-clustered index.<\/p>\n
To make this index more effective, we can make it a covering index for this query by including all of the columns the query references, as shown in Listing 14.<\/p>\n
DROP INDEX IX_vCustomerOrders_Name ON Sales.vCustomerOrders;\nGO\n\nCREATE NONCLUSTERED INDEX IX_vCustomerOrders_Name\n                          ON Sales.vCustomerOrders(Name)\nINCLUDE (SalesOrderID, CustomerID, OrderQty);\nGO\n<\/pre>\n
Listing 14<\/p>\n
When we run the query again, we see an optimized index seek on the non-clustered index. We also see a significantly reduced query cost, down to .0059714.<\/p>\n
Indexed View Requirements<\/h2>\n
An underlying assumption of all previous query examples was use of SQL Server Enterprise Edition. In this edition, SQL Server’s query optimizer will automatically consider indexes on a view when creating a query execution plan. In SQL Server Standard Edition, we can still create indexed views, but the optimizer will not automatically consider its indexes when formulating an execution plan for a query; it will simply access all of the underlying tables. We have to use the WITH (NOEXPAND)<\/code> table hint, directly in the FROM<\/code> clause of each query, to force SQL Server to use the indexed view.<\/p>\n
SELECT <column-list> \nFROM Sales.vCustomerOrders CO WITH ( NOEXPAND );\n<\/pre>\n
Listing 15<\/p>\n
We also noted occasions, even when using SQL Server Enterprise Edition, when we may need to use this hint to get the plan we expect. However, it can be dangerous to boss the query optimizer around, telling it what it can or can’t do. Bear in mind also that if you write queries in stored procedures, your applications, or reports that use WITH (NOEXPAND)<\/code> and then drop the index on the view at a later point in time, the queries that reference that index will fail. In short, the same proviso applies here as applies to the use of any table (index), join, or query hints: use them cautiously and sparingly, and document them.<\/p>\n
As well as this requirement when using views on Standard Edition, there is a lengthy list of ‘requirements’ attached to the creation of indexed views, in any SQL Server Edition. We’ve encountered several already, in the need to create them with the SCHEMABINDING<\/code> option, use fully qualified table references, and use COUNT_ BIG ( *)<\/code> if the view definition contains a GROUP BY<\/code> clause. Another, implied but not discussed directly, is that the indexed view definition can only reference tables, not other views.<\/p>\n
The Microsoft documentation (http:\/\/msdn.microsoft.com\/en-us\/library\/ms191432.aspx) provides a full list of limitations and requirements, so I’ll just briefly summarize some of the more significant here:<\/p>\n