========================================
XML Documents and When to Use XML vs. a Relational Database
========================================
An XML Document With Two People
==========================================
.. code-block:: xml
John
Doe
johndoe@example.com
585-555-0142
Jane
Doe
janedoe@example.com
585-555-0198
An XML Document With One Person and Multiple Addresses
================================================================
.. code-block:: xml
John
Doe
johndoe@example.com
412 Monroe Avenue
Rochester
NY
14607
USA
1800 Main Street
Suite 300
Buffalo
NY
14202
USA
77 Lakeshore Drive
Rochester
NY
14468
USA
Notice that the second document nests the addresses *inside* the person. XML
handles this naturally because it is a hierarchical (tree-shaped) format, and a
person can have one address or ten without changing the structure.
When You Would Use XML
======================
**1. Exchanging data between two different systems.**
XML is plain text and self-describing, so a Java application can send an XML
file to a Python application and both sides can read it. This is why formats
like SOAP web services, RSS feeds, and health-care's HL7 standard use XML. The
tags travel with the data, so the receiving system does not need a copy of your
database schema to understand what it received.
**2. Documents with mixed content and irregular structure.**
Think of a book, a legal contract, or a scientific paper. Some chapters have
footnotes, some have images, some have neither. XML lets each element carry
whatever child elements it needs. Trying to force that into fixed table columns
would leave you with dozens of mostly-empty fields.
**3. Configuration files.**
Files like Maven's ``pom.xml``, Android's ``AndroidManifest.xml``, or a Tomcat
``web.xml`` are read once when a program starts. They need to be human-readable
and editable in any text editor, and they are naturally nested (a project
contains dependencies, a dependency has a version). A database would be
overkill for something a program reads a single time at startup.
When You Would Use a Relational Database
========================================
**1. An application with many users reading and writing at the same time.**
An online store's inventory, a bank's account balances, or a university's
registration system all need transactions. A relational database guarantees
ACID properties, so two people cannot buy the last item at the same moment or
withdraw the same $100 twice. An XML file has no locking, no transactions, and
no way to safely handle concurrent writes.
**2. Querying and reporting across large amounts of data.**
If you want "all customers in New York who ordered more than $500 last quarter,
sorted by total spend," SQL does that in one indexed query across millions of
rows. Searching the equivalent XML would mean parsing the whole file into
memory and walking the tree every single time.
**3. Data with lots of relationships that must stay consistent.**
Students enroll in courses, courses have instructors, instructors belong to
departments. A relational database stores each fact once and links the tables
with foreign keys, so updating a department name updates it everywhere.
Foreign key constraints also block bad data, such as an enrollment pointing to
a course that does not exist. In XML you would repeat the same information in
many places, and nothing stops those copies from drifting apart.
Summary
=======
.. list-table::
:header-rows: 1
:widths: 20 40 40
* - Consideration
- XML
- Relational Database
* - Shape of data
- Hierarchical / nested
- Tabular rows and columns
* - Best at
- Moving and storing documents
- Storing and querying live data
* - Structure
- Flexible, varies per record
- Fixed schema, enforced
* - Concurrent users
- Not supported
- Fully supported with transactions
* - Searching
- Parse the whole file
- Indexed SQL queries
The short version: use XML when data needs to **travel** between systems or be
stored as a self-contained document, and use a relational database when data
needs to **live** somewhere, be updated by many people, and be queried quickly.