Faster at what? A database will almost certainly be faster than writing your own code to do everything done, because it will already be debugged and optimised.

But if you're trying to say that accessing the same data through a database is faster than reading the data directly from a file with stuff like fopen() fread() then you need your head examining. A database will need to lookup the index, work out which block it's in, setup read consistency, check for exclusive locks that would prevent you reading the data, and multitask that with all the other stuff that goes on. There's no way on this planet that database access will be quicker than simple file access.

You wouldn't choose a database just because you need to store some data, you would choose it for the features it provides and for the fact that you don't have to write all that code yourself. If you don't need a database then just bung everything in flat files and take the performance benefit.

> A database can have
better security, because it has its own permission and authentication
system, while file-based sessions often end up owned by "nobody"

Wrong. Who owns the database files? Security of the filesystem is not a reason to pick database over flat file storage; make sure the files are owned by the relevant people and standard OS security will do the job. On the other hand, if the database files are owned by "nobody" then you get exactly the same problem: anyone can do anything with those files. The fact that you don't know how to setup security on data files is not an argument for a database.

> Test with condition where names start with 'A'!
> Flat File time span to do the operation ==> 0.11205410957336 .
> Database time span to do the operation ==> 0.018458127975464 .
> Database operation was faster by 0.093596

You have to do same thing of course for the comparison to be meaningful. In the "names beginning with A" test where the database was faster, the non-database was hampered by the fact that it was doing a regexp comparison of "^a" on each record; that's going to be a hell of a lot slower than doing "if str[0]=='a'" which is basically all that a "like 'A%'" has to do, or maybe "like 'A%'" will do a strncmpi() or similar). The database part of it used "$r = mysql_query("Select f1 from t1 where f1 like 'a%'");" - like and eregi are completely different operations and I would suggest to be fair you should make the database do a regexp lookup instead and see how well it fares.

Also I think the test for writing to a database and file could be improved substantially. Most of the time is going to be taken in opening and closing the file in the file test, and connecting and disconnecting in the database test. Instead of writing a single record, write 1,000,000 and divide the resulting time by 1,000,000 to get a time per record instead; this will be a far more meaningful comparison. Also you could open the file and connect to the database FIRST, then start the timing, write the data, stop the timing, then close the file and disconnect, then the timings will only relate to the record write and not to all the other gubbins.

File access WILL be faster, no question, because except for in-memory databases, a database will have to get the data from a file anyway, plus all the other RDBMSy stuff it has to do. Of course, it's perfectly possible to write highly optimised code against the database and really bad code against the files, and the results will be skewed in favour of the database. That doesn't prove the database is faster, it only proves that crap code is slower than good code.

Also you'll need to run the benchmark test several times to eliminate caching effects. The first run will be skewed by the fact that everything has to be loaded from disk and subsequent runs will be more reliable.

Last edited by xpi0t0s; 7Dec2008 at 02:25..
shabbir like this