XML as a Data Layer for a PHP application

Question

I was wondering how i should go about writing an XML data layer for a fairly simple php web site. The reasons for this are:

1. db server is not available.
2. Simple data schema that can be expressed in xml.
3. I like the idea of having a self contained app, without server dependencies.
4. I would possibly want to abstract it to a small framework for reuse in other projects.

The schema resembles a simple book catalog with a few lookup tables plus i18n. So, it is quite simple to express.

The size of the main xml file is in the range of 100kb to 15mb. But it could grow at some point to ~100mb.

I am actually considering extending my model classes to handle xml data. Currently I fetch data with a combination of XMLReader and SimpleXml, like this:

public function find($xpath){            

    while($this->xml_reader->read()){

        if($this->xml_reader->nodeType===XMLREADER::ELEMENT && 
           $this->xml_reader->localName == 'book' ){


            $node = $this->xml_reader->expand();
            $dom = new DOMDocument();
            $n = $dom->importNode($node, true);
            $dom->appendChild($n);
            $sx = simplexml_import_dom($n); 


            // xpath returns an array

            $res = $sx->xpath($xpath);

            if(isset($res[0]) && $res[0]){

                $this->results[] = $res;                        
            }
    }

    return $this->results;
}

So, instead of loading the whole xml file in memory, I create a SimpleXml object for each section and run an xpath query on that object. The function returns an array of SimpleXml objects. For conservative search I would probably break on first found item.

The questions i have to ask are:

1. Would you consider this as a viable solution, even for a medium to large data store?
2. Are there any considerations/patterns to keep in mind, when handling XML in PHP?
3. Does the above code scale for large files (100mb)?
4. Can inserts and updates in large xml files be handled in a low overhead manner?
5. Would you suggest an alternative data format as a better option?

Answer 1

I would go with SQLite instead, which is perfect for small websites and x-copy style deployments.

XML-based data storage won't scale well.

"SQLite is an ACID-compliant embedded relational database management system contained in a relatively small (~225 kB) C programming library. The source code for SQLite is in the public domain.

Unlike client-server database management systems, the SQLite engine is not a standalone process with which the program communicates. Instead, the SQLite library is linked in and thus becomes an integral part of the program. It can also be called dynamically. The program uses SQLite's functionality through simple function calls, which reduces latency in database access as function calls within a single process are more efficient than inter-process communication. The entire database (definitions, tables, indices, and the data itself) is stored as a single cross-platform file on a host machine. This simple design is achieved by locking the entire database file at the beginning of a transaction."

Answer 2

No, it won't scale. It's not feasible.

You'd be better off using e.g. SQLite. You don't need a server, it's bundled in with PHP by default and stores data in regular files.

Answer 3

If you have a saw and you need to pound in a nail, don't use the saw. Get a hammer. (folk saying)

In other words, if you want a data store, use a data-base, not a markup language.

PHP has good support for various database systems via PDO; for small data sets, you can use SQLite, which doesn't need a server (it is stored in a normal file). Later, should you need to switch to a full-featured database, it is quite simple.

To answer your questions:

1. Viable solution - no, definitely not. XML has its purposes, but simulating a database is not one, not even for a small data set.
2. With XML, you're shuffling strings around, all the time. That might be just bearable on read, but is a real nightmare on write (slow to parse,large memory footprint, etc.). While you could subvert XML to work as a data store, it is simply the wrong tool for the job.
3. No (everything will take forever, if you don't run out of memory before that).
4. No, for many reasons (locking, re-writing the whole XML-string/file, not to mention memory again).

5a. SQLite was designed with very small and simple databases in mind - simple, no server dependencies (the db is contained in one file). As @Robert Gould points out in a comment, it doesn't scale for larger applications, but then

5b. for a medium to large data store, consider a relational database (and it is usually easier to switch databases than to switch from XML to a database).

Answer 4

Everyone loves to throw dirt on XML files, but in reality it works, I've seen large applications use them, and I know of an MMO that uses simple flatfiles for storage and it works fine( by the way the MMO is among the top 5 worldwide, so it's not just a toy). However my job right now is creating a better and more savy persistence layer based on SQL, and if your site will be big SQL is the best solution but XML is capable of Massive (MMO) scalability if done well.

But a caveat is migration from XML to SQL is rough if the mapping isn't easy.