SQLite vs SimpleXML; For small redundant data

stewart · 02-24-2008, 08:33 PM

Alright, on a PHP application/website of mine I will be loading some featured items, which will simply consist of urls, names, ids, and a few small descriptions..

But they will be reloaded constantly, every page, etc.. This isn't the only instance I have this
similar... situation ? , but what would be better here speed and performance wise..

The PHP SQLite class or the SimpleXML class ? I mean I guess it comes down to which one takes up less memory, but which one would operate faster for small bits of information ?

Currently I have an xml file storing all of my featured items and such for my site, then I use the SimpleXML class to retrieve all of this information and draw it onto the page. This is much better than requery-ing my database everytime.. but what about SQLite ?

SQLite seems like there is just more to it than some simple XML rendering, but I could be wrong ? It is pretty much just fopen with a different name.

If anything I'm going to implement SQLite for something, some smaller db operations I guess, but I'm not thinking it is the better solution here, but then again thats why I'm asking!

All thoughts and opinions are appreciated!

Thanks !

- Stewart

SOCK · 02-24-2008, 09:38 PM

SQLite is a relatively full featured RDBMS, albeit using a single db file instead of a client server model. It's a bit more than 'fopen with a different name'. Just about anything you might want to do with MySQL can be done with SQLite. I wouldn't build an authentication system with it, but it's good for basic data storage / logging / etc.

I've been working with JSON a bit lately, although it's primarily in XHR requests, you might consider it an alternative to XML.

Prepare some tests with XML / SQLite / JSON and run benchmarks against them. I'm guessing JSON will be on top with SQLite not far behind and XML the slowest / most intensive of the bunch.

JayGodse · 03-13-2008, 03:29 PM

Hi Stewart.

A few questions you need to ask:
1) Does each page access exactly the same data from the XML file?
2) Is the number of pages going to stay constant over time, or is it increasing?
3) Is the XML file "small" or "large"?
4) Will the content of the file stay the same during web site operation?
5) Will you write to the file during web site operation?
6) Will you need more such XML files over time?
7) Did you choose XML because you need to share data with another application?

If your answer to most of these questions is "yes", then stay with the XML file. It already works, and that is its biggest value now.

If your answer to most of these questions is "no", then you will end up spending time and money tuning the access, storage, update, performance, and consistency of the data in that file(s). You would be much better off using SQLite in this case.

If you are repeatedly reading from the file, XML or SQLite, your program will spend a lot of time parsing either XML or SQLite queries. If your file grows, the SQL gets cheaper to parse. If your program spends time traversing the file looking for stuff, SQLite probably wins with a big file because it implements a B-Tree under the covers, while you need to do a linear search with the XML every time. This performance stuff is moot if your file is "small".

See my site at SQLite The Hammer on Squidoo for more thoughts on SQLite.

SOCK · 03-13-2008, 06:36 PM

Nice, thanks Jay. Bookmarked your site.

stewart · 03-14-2008, 10:10 PM

Thanks for the few tips/ideas Jay ;D

I plan on keeping it with XML, they're all of the featured items listed on my home page and throughout the site (which are the same..)

A few of the entries (only 9..) will change fairly often, but not too much.. and my xml file is quite small, no need for db type functions..

Thanks again, even if its your only post to get a plug to your site ;D hah