[EmployeeID] ASC ) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE PRIMARY XML INDEX PriI_Employee_EmployeeInfo ON Employee(EmployeeInfo)
GO
This time it worked successfully because before a primary XML index can be created, a clustered index must exist on a primary key column (see commandment 4 in the “10 Commandments of XML Index Creation” section later in this chapter). This is for insurance reasons. If the base table is partitioned, the XML index also gets partitioned along with the table.
Figure 6-3 shows the results of the table and index creation.
Figure 6-3
As you can see from Figure 6-3, the code created a Non-Clustered index on the EmployeeInfo column.
It is not necessary to specify in the CREATEstatement whether to create a Clustered or Non-Clustered index because by specifying PRIMARY, the CREATE INDEXstatement knew that there was already a Clustered index on the primary key, and to create the PRIMARY XMLindex as Non-Clustered.
Once the index is created you can go into its properties and try to change it to a Clustered index, only to have SQL Server balk at you for trying to drop the existing Clustered index, thus breaking the rule stated previously about needing a clustered primary key to create the index.
Trying to drop the primary index with secondary indexes associated to it also generates an error.
Secondar y XML Index
Secondary XML indexes can be added to xmldata type columns to provide additional query perfor-mance. Having a primary index on an xmldata type column without any secondary XML indexes may not prove to be beneficial, especially for columns with large XML documents. Querying a large XML instance based on path values can be very time consuming, and a single primary index may not provide the best performance. In these cases, adding secondary XML indexes specifically designed for certain query expressions can prove to be very beneficial.
There are three different types of secondary XML indexes depending on what you are querying, but regardless of the secondary XML index type, a primary XML index must exist prior to creating any sec-ondary XML index.
The three types of secondary XML indexes are:
❑ PATH
❑ VALUE
❑ PROPERTY
As shown in Chapter 2, the basic syntax of a secondary XML index looks like the following:
CREATE XML INDEX SecondaryXMLIndexName ON TableName ( xml_ColumName )
USING XML INDEX PrimaryXMLIndexName FOR [PATH | VALUE | PROPERTY]
SecondaryXMLIndexNameis the new name of the secondary XML index to be created. TableNameis the table on which to create the new secondary XML index. ColumNameis the column on which to create the new secondary XML index. PrimaryXMLIndexNameis the primary XML index on which to base the sec-ondary XML index.
PATH
You use the PATHsecondary XML index when using path expressions in your query. You can determine that you need a PATHsecondary XML index by looking at the WHEREclause of your SQL statement. If there is an exist()method on the xmlcolumn, you are using a PATHexpression and could most likely benefit from this type of index.
For example, the Instructions column in the Production.ProductModel table already has a primary XML index on it, and the following code adds a secondary PATHXML index:
CREATE XML INDEX SecI_PM_I_PATH ON Production.ProductModel(Instructions) USING XML INDEX PXML_ProductModel_Instructions
FOR PATH GO
Figure 6-4 shows that the new PATHsecondary XML index has been created.
The PATHsecondary XML index created is based on the primary XML index called PXML_ProductModel_
Instructionsand improves any path expression queries made on this column. For example, the follow-ing query (used previously) uses the exist()method to check for the existence of a location with a LocationIDattribute with a value of 50:
SELECT Instructions.query(‘
declare namespace MSAW=”http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelManuInstructions”;
for $var in /MSAW:Location[@LocationID=”50”]
return
$var
‘) as Location
FROM Production.ProductModel
WHERE Instructions.exist (‘declare namespace
MSAW=”http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/
ProductModelManuInstructions”;
/MSAW:Location[@LocationID=”50”]’) = 1
Since there is now a secondary XML index on the Instructions column, the XML instance does not need to be shredded, making querying the XML instance faster.
VALUE
When querying for specific values in an XML instance, you should use the VALUEindex, especially when the name of the node or element isn’t exactly known or the path includes a wild card character.
Add a VALUEindex onto the Instructions column by running the following SQL statement:
CREATE XML INDEX SecI_PM_I_VALUE ON Production.ProductModel(CatalogDescription) USING XML INDEX PXML_ProductModel_CatalogDescription
FOR VALUE GO
Figure 6-5 shows that the new VALUEsecondary XML index was created.
Figure 6-5
Just like the PATHindex, the VALUEindex was created based on the primary XML index and improves any value expression queries made on this column. For example, the following query executes a value() expression query to return the ProductID and Name columns from the Production.Product table if the picture size “small”is found:
WITH XMLNAMESPACES (
‘http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription’ AS p1)
SELECT ProductModelID, Name FROM Production.ProductModel
WHERE CatalogDescription.exist(‘//p1:Picture/Size[.=”small”]’) = 1
In the following partial results, there are a number of ProductID and Name columns containing the value “small”:
ProductID Name
19 Mountain-100 23 Mountain-500 25 Road-150
There will be times when you are looking for a specific piece of data and want to query off that key piece of information. The VALUEindex helps improve query performance when those times arise.
PROPERTY
The intent of the VALUEindex is to speed up searches for single values within an XML instance, but if you are searching for multiple values, such as “find all manufacturing steps for a specific Location” or
“find the steps and material for a specific Location,” the VALUEindex for this type of search is not ade-quate. But the PROPERTYindex is made exactly for this type of search.
For this example you need to add a PROPERTYindex onto the Instructions column by running the fol-lowing SQL statement:
CREATE XML INDEX SecI_PM_I_PROPERTY ON Production.ProductModel(Instructions) USING XML INDEX PXML_ProductModel_Instructions
FOR PROPERTY GO
Figure 6-6 shows that the new PROPERTYsecondary XML index was created.
Consider the following query:
WITH XMLNAMESPACES (‘http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelManuInstructions’ AS “PD”)
SELECT ProductModelID,
Instructions.value(‘(/PD:root/PD:Location/@LocationID)[1]’, ‘int’) AS LocationID, Instructions.value(‘(/PD:root/PD:Location/@MachineHours)[1]’, ‘int’) AS MachineHrs FROM Production.ProductModel
WHERE ProductModelID = 7
The results of this query produce three columns, as shown in the following results. The value of the first column is the ProductID, which is returned from the ProductID column in the table. The values of the second and third columns, however, are returned from the XQuery, which retrieved the LocationID and MachineHoursattributes from the first location:
ProductID LocationID MachineHrs 7 10 3
Because multiple values were returned, the PROPERTYindex was utilized in the query. The PROPERTY index kicks into play with the value()method of the xmldata type. It is also beneficial to know the pri-mary key, in this case the ProductID column.
Secondary indexes are a great way to improve query performance, especially when the size of the XML instance is large. Because multiple secondary indexes can be applied to a column, it is a good idea to apply the different types as needed.
The secondary indexes are applied to the xmldata type to help speed up your queries and return your results to you faster. In addition, indexes can also be applied to content, which is discussed in the next section.