Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: open
Advantages of xml
Advantages of mysql
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.
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.
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.