Modern RDBMS\'s have support for XML column types and functionality for dealing with XML in stored procedures. Historically I would always have mapped hierarchical data (whe
The only reason I would ever use it again is when for extensibility & flexibility.
The overhead of xml (xpath) and maintenance (namespaces) are really not worth the hassle if you can avoid it. We have previously stored large amounts of data in xml and used scalar functions to retrieve it, but it is too slow and causes immense headaches is the xml structure or namespace changes.
But the flexibility is fantastic. You can add new properties whenever you want, you can have project/client/job specific data in there which doesn't require proper columns. The XML does not have to be in a static structure - you simply need a factory which can spawn instances to deal with the different XML (which would need to be related to a project/client/job).
When adding a new table to an existing system, especially one that has a lot of existing data and can't easily be modified, I will add an XML column. In the future if I ever need to add another column to that table, I can simply utilise the XML column rather than being frustrated and having to do a lot of rework.
In summary, you don't start out by putting essential properties in XML. But you should add XML when you know that your table might need to be extended, precisely because it gives you the option of extending.