SPECIAL CONSIDERATIONS WHEN USING XQUERY Special Considerations When

SPECIAL CONSIDERATIONS WHEN USING XQUERY Special Considerations When Using XQuery inside SQL Server Using Strongly Typed XML with XQuery Unlike XPath 1.0, XPath 2.0 and XQuery 1.0 are strongly typed query languages. This is quite evident in the wide range of constructors and casting functions for different data types. The reasoning behind this is that XQuery is built to be optimized, and using strong types rather than using every element and attribute as type stringallows the query engine to do a better job in optimizing and executing the query. Imagine that the Transact- SQL query parser had to deal with everything as a single data type! Every XML data type column, XML variable, and XML procedure parameter can be strongly typed by reference to an XML schema or can be untyped. When typed XML is used in an XQuery, the query parser has more information to work with. If untyped XML is used, the query engine must start with the premise that every piece of data is type string; the xf:data()built-in function can be used with strongly typed data to return the exact data type. XQuery supports static type analysis, meaning that if the types of items that are input to an expression are known, the output type of an expression can be inferred at parse time. In addition, strong typing permits the XQuery language to syntax check the input based on types at parse time, as Transact-SQL can, so fewer runtime errors occur. XQuery also allows the query processor to reorder the queries; although this is a performance optimization, this could on occasion lead to runtime errors. You ve seen a very noticeable example of SQL Server XQuery s strong typing in almost all the example queries in this chapter. In these queries, whenever a function or return value requires a singleton, we must use the [1]subscript to ensure it s really a singleton; otherwise, a parse-time error results. Almost all other XQuery processors (without strong typing) will execute the query and produce a runtime error if the value is not actually a singleton. If we had a strongly typed XML column instead, in which the schema defined the elements we re referring to as maxOccurs=1 minOccurs=1 (the default), a query without the subscript would succeed, because the parser knows that the element in question is a singleton. Having a schema-validated column permits you to do the type-checking at column insert/update time, rather than take the extra measure of requiring a subscript to enforce it at XQuery parse time.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

Bookmark the permalink.

Comments are closed.