Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Chapter 16: A Brief XML Primer 2. We have allowed NULLs but could have just as easily chosen NOT NULL as a constraint. Note, however, that the NOT NULL would be enforced on whether the row had any data for that column, not whether that data was valid. 3. Our XML is considered “non-typed XML.” That is, since we have not associated any schema with it, SQL Server doesn’t really know anything about how this XML is supposed to behave to be considered “valid.” The first of these is implied in any column that is defined with the data type XML rather than just plain text. We will see much more about this in our next XML data type section. The second goes with any data type in SQL Server — we can specify whether we allow NULL data or not for that column. So, the real meat in terms of changes we can make at definition time has to do with whether we specify our XML column as being typed or non-typed XML. The non-typed definition we used in the preceding example means that SQL Server knows very little about any XML stored in the column and, therefore, can do little to police its validity. If we set the column up as being typed XML, then we are providing much more definition about what is considered “valid” for any XML that goes in our column. The AdventureWorks2008 database already has schema collections that match the validation we want to place on our two XML columns, so let’s look at how we would change our CREATE statement to adjust to typed XML: CREATE TABLE Production.ProductModel ( ProductModelID int IDENTITY(1,1) PRIMARY KEY NOT NULL, Name dbo.Name NOT NULL, CatalogDescription xml (CONTENT [Production].[ProductDescriptionSchemaCollection]) NULL, Instructions xml (CONTENT [Production].[ManuInstructionsSchemaCollection]) NULL, rowguid uniqueidentifier ROWGUIDCOL NOT NULL, ModifiedDate datetime NOT NULL CONSTRAINT DF_ProductModel_ModifiedDate DEFAULT (GETDATE()) ); This represents the way it is defined in the actual AdventureWorks2008 sample. In order to insert a record into the Production.ProductModel table, you must either leave the CatalogDescription and Instructions fields blank or supply XML that is valid when tested against their respective schemas. XML Schema Collections 488 XML schema collections are really nothing more than named persistence of one or more schema documents into the database. The name amounts to a handle to your set of schemas. By referring to that collection, you are indicating that the XML typed column or variable must be valid when matched against all of the schemas in that collection. We can view existing schema collections. To do this, we utilize the built-in XML_SCHEMA_NAMESPACE() function. The syntax looks like this: XML_SCHEMA_NAMESPACE( , , [] )
This is just a little confusing, so let’s touch on these parameters just a bit: Parameter Description So, to use this for the Production.ManuInstructionsSchemaCollection schema collection, we would make a query like this: SELECT XML_SCHEMA_NAMESPACE(‘Production’,’ManuInstructionsSchemaCollection’); This spews forth a ton of unformatted XML: Chapter 16: A Brief XML Primer SQL Server schema This is your relational database schema (not to be confused with the XML schema). For example, for the table Production .ProductModel, Production is the relational schema. For Sales.SalesOrderHeader, Sales is the relational schema. xml schema collection The name used when the XML schema collection was created. In your CREATE table example previously, you referred to the ProductDescriptionSchemaCollection and ManuInstructionSSchemaCollection XML schema collections. namespace Optional name for a specific namespace within the XML schema collection. Remember that XML schema collections can contain multiple schema documents — this would return anything that fell within the specified namespace. 489
- Page 475 and 476: The only cure for this is setting y
- Page 477 and 478: Exclusive Locks Exclusive locks are
- Page 479 and 480: Also: ❑ The Sch-S is compatible w
- Page 481 and 482: The syntax for switching between th
- Page 483 and 484: As with most things in life, howeve
- Page 485 and 486: purchased. Process 2 records sales;
- Page 487: Chapter 14: Transactions and Locks
- Page 490 and 491: Chapter 15: Triggers the world’s
- Page 492 and 493: Chapter 15: Triggers WITH ENCRYPTIO
- Page 494 and 495: Chapter 15: Triggers FOR|AFTER The
- Page 496 and 497: Chapter 15: Triggers 458 To illustr
- Page 498 and 499: Chapter 15: Triggers 460 IF EXISTS
- Page 500 and 501: Chapter 15: Triggers ❑ Feeding de
- Page 502 and 503: Chapter 15: Triggers Trigger Firing
- Page 504 and 505: Chapter 15: Triggers Like regular t
- Page 506 and 507: Chapter 15: Triggers The COLUMNS_UP
- Page 508 and 509: Chapter 15: Triggers This is the sa
- Page 510 and 511: Chapter 15: Triggers 472 we have th
- Page 512 and 513: Chapter 16: A Brief XML Primer So,
- Page 514 and 515: Chapter 16: A Brief XML Primer Figu
- Page 516 and 517: Chapter 16: A Brief XML Primer Elem
- Page 518 and 519: Chapter 16: A Brief XML Primer ❑
- Page 520 and 521: Chapter 16: A Brief XML Primer 482
- Page 522 and 523: Chapter 16: A Brief XML Primer Name
- Page 524 and 525: Chapter 16: A Brief XML Primer The
- Page 528 and 529: Chapter 16: A Brief XML Primer SQL
- Page 530 and 531: Chapter 16: A Brief XML Primer So,
- Page 532 and 533: Chapter 16: A Brief XML Primer If,
- Page 534 and 535: Chapter 16: A Brief XML Primer 496
- Page 536 and 537: Chapter 16: A Brief XML Primer Note
- Page 538 and 539: Chapter 16: A Brief XML Primer RAW
- Page 540 and 541: Chapter 16: A Brief XML Primer AUTO
- Page 542 and 543: Chapter 16: A Brief XML Primer EXPL
- Page 544 and 545: Chapter 16: A Brief XML Primer Chec
- Page 546 and 547: Chapter 16: A Brief XML Primer 508
- Page 548 and 549: Chapter 16: A Brief XML Primer 510
- Page 550 and 551: Chapter 16: A Brief XML Primer 512
- Page 552 and 553: Chapter 16: A Brief XML Primer The
- Page 554 and 555: Chapter 16: A Brief XML Primer 516
- Page 556 and 557: Chapter 17: Reporting for Duty, Sir
- Page 558 and 559: Chapter 17: Reporting for Duty, Sir
- Page 560 and 561: Chapter 17: Reporting for Duty, Sir
- Page 562 and 563: Chapter 17: Reporting for Duty, Sir
- Page 564 and 565: Chapter 17: Reporting for Duty, Sir
- Page 566 and 567: Chapter 17: Reporting for Duty, Sir
- Page 568 and 569: Chapter 17: Reporting for Duty, Sir
- Page 570 and 571: Chapter 17: Reporting for Duty, Sir
- Page 572 and 573: Chapter 17: Reporting for Duty, Sir
- Page 574 and 575: Chapter 17: Reporting for Duty, Sir
Chapter 16: A Brief XML Primer<br />
2. We have allowed NULLs but could have just as easily chosen NOT NULL as a constraint. Note,<br />
however, that the NOT NULL would be enforced on whether the row had any data for that column,<br />
not whether that data was valid.<br />
3. Our XML is considered “non-typed XML.” That is, since we have not associated any schema<br />
with it, <strong>SQL</strong> <strong>Server</strong> doesn’t really know anything about how this XML is supposed to behave to<br />
be considered “valid.”<br />
The first of these is implied in any column that is defined with the data type XML rather than just plain<br />
text. We will see much more about this in our next XML data type section.<br />
The second goes with any data type in <strong>SQL</strong> <strong>Server</strong> — we can specify whether we allow NULL data or not<br />
for that column.<br />
So, the real meat in terms of changes we can make at definition time has to do with whether we specify<br />
our XML column as being typed or non-typed XML. The non-typed definition we used in the preceding<br />
example means that <strong>SQL</strong> <strong>Server</strong> knows very little about any XML stored in the column and, therefore,<br />
can do little to police its validity. If we set the column up as being typed XML, then we are providing<br />
much more definition about what is considered “valid” for any XML that goes in our column.<br />
The AdventureWorks<strong>2008</strong> database already has schema collections that match the validation we want to<br />
place on our two XML columns, so let’s look at how we would change our CREATE statement to adjust to<br />
typed XML:<br />
CREATE TABLE Production.ProductModel<br />
(<br />
ProductModelID int IDENTITY(1,1) PRIMARY KEY NOT NULL,<br />
Name dbo.Name NOT NULL,<br />
CatalogDescription xml<br />
(CONTENT [Production].[ProductDescriptionSchemaCollection]) NULL,<br />
Instructions xml<br />
(CONTENT [Production].[ManuInstructionsSchemaCollection]) NULL,<br />
rowguid uniqueidentifier ROWGUIDCOL NOT NULL,<br />
ModifiedDate datetime NOT NULL<br />
CONSTRAINT DF_ProductModel_ModifiedDate DEFAULT (GETDATE())<br />
);<br />
This represents the way it is defined in the actual AdventureWorks<strong>2008</strong> sample. In order to insert a<br />
record into the Production.ProductModel table, you must either leave the CatalogDescription and<br />
Instructions fields blank or supply XML that is valid when tested against their respective schemas.<br />
XML Schema Collections<br />
488<br />
XML schema collections are really nothing more than named persistence of one or more schema documents<br />
into the database. The name amounts to a handle to your set of schemas. By referring to that collection,<br />
you are indicating that the XML typed column or variable must be valid when matched against<br />
all of the schemas in that collection.<br />
We can view existing schema collections. To do this, we utilize the built-in XML_SCHEMA_NAMESPACE()<br />
function. The syntax looks like this:<br />
XML_SCHEMA_NAMESPACE( , , [] )