I've been working on database-driven web applications for a few years now and recently took on a project involving a CMS that is XML-capable. This has led me to think about the usage of XML/XSLT in general and in what situations it would be more useful than the approach I've always used, which is storing all of my data in a (My)SQL database and then using PHP/Python/etc. to work with it on the web as needed.
There's obviously something I'm not "getting" here.. could anyone give me examples of applications where storing the data in XML files instead of in a database would be preferable?
Here is an example of using XML with SQL: Authenticated users read and write data to various databases, not all of which are the same DBMS. Users for Company A use data from a local SQL Server database. Users for Company B use data from a remote Oracle database. And so on. A dozen different databases, each with slightly different schemas for the same basic data.
The website developer does not have the ability to create stored procedures on the remote databases. SQL must be sent directly from the web app to the database. Since each database has a slightly different SQL syntax and schema, it is necessary to use different SQL for each of the 12 databases for the same operation (SELECT, INSERT, etc).
One of the choices for embedding the SQL statements in the web app is to place them in XML files. Each XML file contains the set of SQL statements for one of the dozen databases. The code determines which database is accessed for the logged-in user, and retrieves the appropriate SQL from the specified XML file.
Just as with stored procedures, the SQL in the XML file can be updated without stopping or recompiling the application.
Whenever you don't have the luxury of having a database (think single user applications) or need a very lightweight storage format.
Also as the previous poster mentioned, an interchange format.
Some applications use XML files to store configuration, I prefer to use SQLite to do so.
1) When you have to interchange your data with others. XML is the "lingua franca" of the Web -- just about everyone can read and interpret it, unlike a database file.
2) When your data volume is small and you don't have to do complex queries against it. XML files are good for things like storing configuration or document templates.
3) When you don't have many writers trying to access the same data. SQL databases have involved concurrency mechanisms that are working behind the scenes for you. SQL databases can support indexes for the retrieval of information on large data sets quickly...
I believe there are quite a few commercial applications that make heavy use of XML as a storage medium. I've done it for a project planning application, where the user stores each project in it's own file. The app lives on a USB stick, and requires zero install. All the data is pulled from the XML and worked on in memory, so getRecord(id) is nuts fast.
So my answer would be.. when the data is small enough to be held in memory, a database is over kill.
Both XML and RDMSs can be used as datastores, but each implementation has its own advantages and drawbacks.
Using XML to store data for a web application is usually not a big problem until you start dealing with large amounts of data or you decide that you want to discover other information from your data (example: data mining). In other words, storing large amounts of XML files for a datasource is not very scalable but it makes it easier to move the data around. XML can also be used to serialize complex objects in a non-relational format, which could eliminate the need for an ORM if you can serialize/deserialize your objects directly from the XML
RDMSs (databases) are usually more scalable, offer greater concurrency support and are much faster when working with large amounts of data. The relational model makes it easier to data mine later on. Databases do suffer from the object-relational impedance mismatch (http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch) which might require you to write ugly code or use complex ORMs.