Can xml replace mysql?

In some basic situations

[kapow]

I'm trying to find out when xml/xsl is better than mysql for fairly standard website content?
I'm wondering if xml with xsl can replace a lot of stuff we do with mysql. The kind of website builds I'm looking at are:

• Online store with say 500 products (using xml/xsl to store, search, edit, and cart the products).
  
• Brochure site e.g. 10-20 descriptive pages (using xml/xsl to store and edit the content).

The following are the issues I have discovered so far. Can anyone shed any more light on the possibility of replacing mysql with xml?

Advantages of xml

• Ease of manual edit: I can open an xml file in notepad and edit it.
  
• Lots of new media is xml compatible.
  
• Some hosts limit the number of databases you can use. This isn't a problem if the data is in xml files instead.
  
• Easier to move a site to another host (ie I don't need to setup the database).

Advantages of mysql

• Speed: I hear it is faster finding a record in a large database (say 10,000 records). A large xml file could take longer to find the required info (e.g. a product to display). A solution for this is to separate the xml files into multiple (smaller) files e.g. by category.
  One problem I see here is if an 'xml online store' started with 500 products but grew and grew, would there be a size when it would have to be rewritten entirely for a database? If the store were built in mysql in the first place it would grow more easily. - Is this true?
  
• Record-level locking: mysql has built in functions to prevent multiple writes at the same time in the same record.

I understand the two can be combined e.g. storing xml data in a database, but for the sake of this basic research I would like to leave that subject for now.

[cameraman]

The answer to the title of your post is yes, of course.
The answer to 'when' is very subjective, and each developer ultimately forms his/her own criteria.

I typed an answer to this last night, but when I reviewed it I decided 'well this is all just subjective opinionated hooplah' and I deleted it.

Personally, I favor databases because I've been using them for so long. Therefore, the number of records doesn't have to get very big (50 or less) before I turn to that technology. If any sorting or filtering at all needs to be done, it's easier and faster for me to do it via SQL. So I would definitely put products into a database, although I might be tempted to try the articles using XML just to broaden my horizon, so to speak.

I don't have a lot of experience with XML; I've fiddled around with it on and off, and actually that's why I started looking at this particular forum - to learn how I can better use the technology. It appears to me that XML shines its brightest when transferring data between applications and platforms. It also shines brightly when a high degree of formatting has to be applied to the data.

I don't think you can ever beat a well designed database (both engine and data structure) on speed. XML gets to be a little clumsy in terms of storage because it is necessarily so verbose (you don't have to keep writing out 'book', 'book', 'book', 'author', 'author', 'author' in a database table).

Ease of edit/multiple supporting applications is a good point. If your content is coming from several collaboraters via CDs or email, XML would be an excellent medium to use to get ahold of the documents. On the other hand, if I were the sole content writer or my collaborators submitted via internet, I can put together an edit/update page in under 10 minutes (maybe under 5 if I don't get hung up on choosing a background color), so that would be one of my criteria. Another would be the size of the contributions; if I'm doing a site for book writers and the whole book is coming in, it makes more sense (to me) to store it as a file. However, I'd be tempted to store its filename in a table..

"Easier to move a site" is debatable (less direct interaction on your part, perhaps). Database utilities such as phpMyAdmin make backup/restore tasks pretty easy. Hosts which limit the number of databases you can have shouldn't be a major deciding factor - I haven't seen one yet which limits the number of tables you can have. While it may not be ideal, there's no reason you can't combine your CMS, bulletin board, and help desk into one database. I have seen hosts which limit the database's size, but personally I'd choose a different host <grin>.

The number of technologies available to us is just staggering, and it seems to be accelerating if anything. When it comes down to it, a well-rounded web developer needs to be intimate with a few, keep several more nearby, and keep abreast of what may need to be learned should the occasion arise. Which ones to use and when can always be argued, but really what it comes down to is "how's it look in the browser" - hard drives keep getting bigger and processors keep getting faster - sounds like a hardware problem <evil grin>...

Oh crud, looks like this is still subjective opinionated hooplah. Oh well.

[ronburk]

I hear it is faster finding a record in a large database

For the sizes you are talking about, it is entirely practical to just use XSLT to generate static HTML from XML "database" files. Web servers are highly optimized to serve static HTML fast, so there is little chance an SQL database will approach this with regards to speed.

For example, I keep a product summary "database" for about 200 products in a single XML file, where it's fairly easy to edit. After making changes to that file, I push a button and have XSLT generate the 200 static HTML product files (along with a lot of automatic indexing and inter-linking and error checking).

IOW, all of the XML and XSLT activity takes place on my desktop, and my web server (and visitors) only see static HTML files.

There's no need to have a 1-to-1 relationship between .xml and .html files, except where that happens to be the most convenient arrangement.