[Resolved] IO Vs Database -

simon622

Hi ppl. I really should just benchmark this, but time being a constraint, thought Id se if anyone on here had any pearls of wisdom.

Must be a common question..

Is general IO using php's fread() method (combined with the initial fopen - to get the file handle) quicker or slower than database reads - this would be a full table read, with n rows (prb >1000 - nothing too heavy); As i know that at a DB level all the DBMS is doing is IO?

Ill give this question context now:

I am a java bod at heart and I love the java .properties file, e.g.:

somePro=someValue
someOtherProp=someOtherValue

I have written an object simlar to that of the Properties object in java, that allows retrieval of these strings into variables within the object scope.

however I have found this to be quite slow in php, especially when reading large number of properties. It would be great if we had some kind of funky caching that I could use for this, e.g. read them in once and access them all (as they are all static) from a lookup somehow.. (this was a hint to see if anyone knows of any such thing)

thanks all,

laserlight

Ill give this question context now:

I am a java bod at heart and I love the java .properties file, e.g.:

somePro=someValue
someOtherProp=someOtherValue

I have written an object simlar to that of the Properties object in java, that allows retrieval of these strings into variables within the object scope.

You could look into using PHP's [man]parse_ini_file/man.

Weedpacket

One advantages that a decent DBMS would have is that it would probably cache the table in core, avoiding the need for disk read/writes. Whether that's enough to offset having the DBMS in there as well ... I think to some extent it depends on the choice of DBMS.

AstroTeg

I'm not an expert, but I'd think if all you're doing is reading in a file sequentially (no searches until the file is loaded in memory) and assuming the file can fit into memory, it would be pretty fast and probably a good way to go. But if you need it to scale to a larger size or pull only a couple records at a time, then a database would be the way to go (add some indexing as needed to improve the search performance).

simon622

Thanks for all your great responses ppl. This is why I think the php community is the best there is!!!

laserlight, I was aware of the parse_ini_file(), I wrote my own as I needed some more java like behaviour from it - primarily as Im porting the property files from a j2ee app, also It means it is all nicely encapsulated.

Regarding RDBMS level caching, unfortunately, we only have the ability to use mySQL 3.x, (one of the reasons we're moving from ORA Vs J2ee to PHP Vs MySQL is cost - little plug for the community there!!!) I dont think query caching is available until the 4.x release. (I may be wrong on this - if so please correct me).

I think the real hub of the question, after rethinking a little bit, was;

Scenario:

I parse a property file into memory using (at low level granularity, fopen and fread) parsed into some trivial data structure, lets say for the sake of arguement an assoc array. encapsulated in a nice Property obj.

How do you think, would be my best way of persisting this datastructure (preferrably maintaining its namspace association with the object, altho this is not 100% required.. would just be nice ;-) )

For arguements sake, this object is too large to persist in the session, as it may well contain n000's of key=>val's, and I dont want them kicking around with every user. I really want a nice bit of memory, available across global scope, so that user 1 thru n all has access to the Property obj without having to re-parse the file?? I guess I want a jndi lookup in php!! :-)

I have dabbled with serialising the object but even then to persist it, I go back to IO Vs DB, and regarding serialisation, Ive noticed this implementation in PHP basically sucks, as an awful lot of object integrity is lost :-(

sorry for the long winded response, any ideas graciouslly recieved!!