I found out tonight that such things exist. I wonder, would the option of using of an XML database with Symphony potentially make sense? It would enable use of XQuery with XPath syntax to grab data, which I find intriguing having started to learn and use XSLT.

I'm still very much getting to grips with the whole XML ecosystem (up until Symphony CMS and XSLT, XHTML for web pages was my only real experience of it), and with all the talk of databases going on at the moment I thought I'd throw this vague thought up here and maybe get developers' thoughts and insights on the topic in general.

XML databases has been around for a while and has been discussed internally since before Symphony 2.0 had been planned.

In the end we opted against it for the following reasons:

  • XML databases are new and relatively untested (bearing in mind this was a few years ago).
  • Regardless of format, content data in a CMS space, are in essence highly relational.
  • Most preconfigured hosting environments do not come bundled with XML databases.
  • Majority of server administrators are not familiar with XML databases.

XML database is certainly attractive when it comes to its obvious convenience benefits such as XQuery/XPath selects. However, it also needs to be easy to manipulate the data structure (i.e. dropping a field from a section), be robust (i.e. millions of records over thousands of connections) and offer the same suite of features and functionalities that a more matured systems provide (i.e. distributed systems, query cache, etc.)

I haven't looked at XML databases recently so some of our initial concerns may no longer be an issue, but at the end of the day, the biggest concern is user install base. Going with an XML database may mean a large portion of our users will no longer be able to run Symphony on their environment. Bear in mind that RDMS and XML DB are fundamentally different in concept and implementation so they cannot happily coexist as far as support in Symphony is concerned.

If we're talking pure hypotheticals, one would think the ideal choice would be to port Symphony over to JSP so that it can run SAXON (XSLT 2) over an XML DB and come bundled with Apache FOP support for XSL-FO processing, but doing so would likely alienate the majority of our existing users.

but doing so would likely alienate the majority of our existing users.

Yep. I hate JSP. Saying that though, I've started using neo4j databases, with a PHP bridge and it looks really cool, although it is on Java, which I dislike intensely...

I think that just abstracting out the structure to XML will solve most of any problems we have, data should still remain in MySQL. AS I've discussed before, we can look at DB abstraction at a later date for other DBMSs. Jens' talks and ideas about PDO will make that step so much easier.

Moving in the right direction, but I agree with Allen about the XML DB route.

Thanks, Allen. I can see your points make sense.

Just thinking aloud: do you see any scope for being able to use XQuery to read from a MySQL database (or an XML representation of it)? Maybe an extension would be able to periodically perform the function of converting relational data into XML. Something like that would likely involve performance and other issues, I guess.

Just seen your post, John. I'd be interested to hear how you get on with Neo4j in general - that caught my eye, too.

Just thinking aloud: do you see any scope for being able to use XQuery to read from a MySQL database (or an XML representation of it)?

Yes, this has been considered. In fact, the talk I gave at the 2010 Symposium, I mentioned a method of creating performance-focused index tables which stores partially rendered XML snippets came from the early discussion I had with Scott, Alistair and Rowan on the topic of building an XML DB-like infrastructure within the confines of a RDBMS (it later morphed into the notion of schemaless DB, then ultimately became the idea of DS performance tuning using index tables).

Anyway, it's possible to consider a intermediary layer that provides XQuery support, but the main problem here would be that the the relationship of data would be unidirectional, i.e.:

  • Data needs to be stored in the DB through RDBMS means (SQL).
  • The system generates XML based on the data in the DB.
  • Requests are made through XQuery/XPath
  • Content update is done through SQL
  • The system regenerates the XML based on the data in the DB.

DB Writes cannot be done through the XML file layer then to the RDBMS.

Without fully embracing what XML DB offers, intermediary solutions only slows the process by adding more layers to an otherwise straightforward approach.

Regarding my point about the DB optimisation through index tables, for those that heard my talk and suggested MySQL views, I just want to point out that MySQL views are pseudo temporary tables and its main purpose is to allow developers to build simpler queries on highly normalised or complex table structures. It however does not provide any performance gains, in fact it's a bit slower. This is because MySQL views are built in run-time before the user's query is run against the temp table.

Simple queries that run against physical index tables offer performance gains at the cost of additional file space and DB update performance.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details