XML vs MySQL

[Serenarules]

I am writing a custom forum for a website I own.. We have been using another system until now and find it too bloated for our tastes. Over the course of about four years we've generated a total of under 50,000 posts. Small right? Well, I was wondering how far storing things in XML would take me? We have had bed experience switching hosts (several moves) just to find the new host is running a different version of MySQL and can't import old data. We wanted something we can just move and go with. My intentions were to use a separate xml file for each "table" using a format like the following:

[xml]
<records seed="1">
<record .... />
...
</records>
[/xml]

The posts table doesn't even have ten fields in it, which of course would be node attributes, so how many records would it be able to hold without slowing things down tremendously?

[edit]

You guys should add an [xml] bbcode. Heh.

[Mittineague]

Although there are similarities between using XML and MySQL for data storage, IMHO XML is better for data transfer than for storage when you're dealing with larger amounts of data. *see http://www.sitepoint.com/forums/showthread.php?t=600374

There already is an "XML bbcode", it's in the "syntax" dropdown.

[Serenarules]

Yes. I understand the differences between, and intentions for, each technology. However, my needs lean me towards xml. Therefore, what I really need to know is how large (in bytes) can an xml file get before it starts to slow down response time? My current biggest MySQL table size is 770732 bytes, so you can see it isn't much now, or probably ever will be. I just want to be safe. Again, just so readers understand what it is I want to do:

Each "table" will have it's own xml file. For example:

categories.xml

<categories seed="3">
<category id="1" ...other attribues... />
<category id="2" ...other attribues... />
</categories>

topics.xml

<topics seed="4">
<topic id="1" categoryid="1" ...other attribues... />
<topic id="2" categoryid="1" ...other attribues... />
<topic id="3" categoryid="2" ...other attribues... />
</topics>

So again, with no more than 10-15 attribute "fields" per row and less than 100,000 element "rows" in the biggest table (posts.xml), will the xml medium perform well?

Note: using XPath for queries and file locking when saving.

I apologize if it seems like I just repeated myself. That wasn't intentional. I just want to make sure people understand what I'm doing, and the question I'm asking.

[wwb_99]

Really depends on the innards of the XPath implementation you are relying upon, but XML will generally be slower and much less reliable than any decent RDBMS for most scenarios. It is probably easier to pay attention to MySql versions when transferring hosts then to write your own Xml RDBS.

A good example of how badly XML scales would be Das Blog. It uses XML to store posts, and interesting things start happening as the file starts getting really big.

[Serenarules]

Well, I thought about that and have a few caveats to my design that might make it perform better.

The only tables I'm worried about size-wise are, in order, posts, topics and users. What I may do is take a look at the way I'm doing things and see if there's a way to logically break those up into smaller tables. For example posts-<topicid>.xml to house only the posts for that topic.

Anyway, thanks for the input.