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

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.

Absolutely not...
SQLite is a sql92 (almost) compliant database engine, without network access that use a binary file with hash trees as a container for it's tables.

It support tables, views, trigger, foreign keys (partial), transactions and is ACID compliant.

SQLite Features:

• Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures.
• Zero-configuration - no setup or administration needed.
• Implements most of SQL92. (Features not supported)
• A complete database is stored in a single cross-platform disk file.
• Supports terabyte-sized databases and gigabyte-sized strings and blobs. (See limits.html.)
• Small code footprint: less than 250KiB fully configured or less than 150KiB with optional features omitted.
• Faster than popular client/server database engines for most common operations.
• Simple, easy to use API.
• Written in ANSI-C. TCL bindings included. Bindings for dozens of other languages available separately.
• Well-commented source code with over 99% statement test coverage.
• Available as a single ANSI-C source-code file that you can easily drop into another project.
• Self-contained: no external dependencies.
• Cross-platform: Linux (unix), MacOSX, OS/2, Win32 and WinCE are supported out of the box. Easy to port to other systems.
• Sources are in the public domain. Use for any purpose.
• Comes with a standalone command-line interface (CLI) client that can be used to administer SQLite databases.

Suggested Uses For SQLite:

• Application File Format. Rather than using fopen() to write XML or some proprietary format into disk files used by your application, use an SQLite database instead. You'll avoid having to write and troubleshoot a parser, your data will be more easily accessible and cross-platform, your updates will transactional.
• Database For Gadgets. SQLite is popular choice for the database engine in cellphones, PDAs, MP3 players, set-top boxes, and other electronic gadgets. SQLite has a small code footprint, makes efficient use of memory, disk space, and disk bandwidth, is highly reliable, and requires no maintenance from a Database Adminstrator.
• Website Database. Because it requires no configuration and stores information in order disk files, SQLite is a popular choice as the database to back small to medium-sized websites.
• Stand-in For An Enterprise RDBMS. SQLite is often used as a surrogate for an enterprise RDBMS for demonstration purposes or for testing. SQLite is fast and requires no setup, which takes a lot of the hassle out of testing and which makes demos perky and easy to launch.

The 2 have nothing in common, although I don't know what is that sqlite class you are talking about.
What I know is that PHP5 can be linked against Sqlite 2, and that you can have access to SQLite 3 with the PDO driver PDO::Sqlite

http://sqlite.org/features.html
http://www.php.net/manual/en/ref.pdo.php
http://www.php.net/manual/en/ref.pdo-sqlite.php

If you just want to read a file that will not change, then use XML.
If you want to store datas and don't need the overload of a full engine like pgsql, then I'd say: use sqlite.

I use it in some projects as a caching recipient.
I query/update it, rather than using the main database.
The advantage is that it's portable. You copy the db file, and you can use it elsewhere.

No need for a dump/restore. No grant/revoke neither though...
You can access the file, then you can insert/update/delete in it with the sqlite client.

Hmmz, thanks for the helpful reply!
I will actually be changing this XML file from time to time, I figured I could either manually edit it or I will probably use the SimpleXML functions to do that through an admin panel as well, just like the main db...

From your description it sounds as though sqlite would work for this as well, but I think the XML method is solid as well..

But I have more of a question as to the performance in speed with the two. I'm sure one or the other takes a hit after so many connections/initiations ? With the XML method I would think it would support high traffic at one point ?

Of course, doing a select in a DB needs more resources than an Xpath query, I'd say (but this can depend upon the class efficiency)

If you want to find out for sure, try to install Xdebug [ http://www.xdebug.org ], enable the profiler, and analyze it trace with something like KcacheGrind (for linux) [ http://kcachegrind.sourceforge.net/cgi-bin/show.cgi ] or winCacheGrind (for windows) [ http://sourceforge.net/projects/wincachegrind ]

It will show you where your script pass it time.
As for the speed of sqlite, it's within the same to faster for the tests I've conducted between mysql, pgsql and sqlite v3.
But, for me, the biggest drawback of sqlite is that it don't support date/time/timestamp field types.

Only alphanumeric and numeric fields are supported. Therefor, there is now CURRENT_TIME, now() nor interval() functions nor constant defined.
You must handle the date computation in your code.
That's the reason why I only put it on specific tasks, and leave most of the work to postgresSql

I'd use text files to store ready-to-go serialized objects. No matter where you store your data initially, in db or xml, you just select it once, refactor if needed, put into array, serialize it and save to file. On next request you unserialize your data back and display it.