I was trying to understand the basic advantage of using XML DataType in SQL Server 2005. I underwent the article here, saying that in case you want to delete multiple records. Serialize the XMl, send it in Database and using below query you can delete it..

I was curious to look into any other advantage of using this DataType…
EDIT
Reasons for Storing XML Data in SQL Server 2005
Here are some reasons for using native XML features in SQL Server 2005 as opposed to managing your XML data in the file system:
-
You want to use administrative functionality of the database server for managing your XML data (for example, backup, recovery and replication).
My Understanding – Can you share some knowledge over it to make it clear?
-
You want to share, query, and modify your XML data in an efficient and transacted way. Fine-grained data access is important to your application. For example, you may want to insert a new section without replacing your whole document.
My Understanding – XML is in specific column row, In order to add new section in this row’s cell, Update is required, so whole document will be updated. Right?
-
You want the server to guarantee well-formed data, and optionally validate your data according to XML schemas.
My Understanding – Can you share some knowledge over it to make it clear?
-
You want indexing of XML data for efficient query processing and good scalability, and the use a first-rate query optimizer.
My Understanding – Same can be done by adding individual columns. Then why XML column?
Pros:
Allows storage of xml data that can be automatically controlled by an xml schema – thereby guaranteeing a certain level of data quality
Many web/desktop apps store data in xml form, these can then be easily stored and queried in the database – so it is a great place to store xml data that an app may need to use (e.g. for configuration settings)
Cons:
Be careful about using xml fields, they may start off as innocent storage but can become a performance nightmare if you want to search, analyse and report on many records.
Also, if xml fields will be added to, changed or deleted this can be slow and leads to complex t-sql.
In replication, the whole xml gets updated even if only one node changes – therefore you could have many more conflicts that cannot easily be resolved.