Matt Nordhoff wrote: > Michael Wieher wrote: >> I'm not sure if a well-written file/seek/read algorithm is faster than a >> relational database... >> sure a database can store relations and triggers and all that, but if >> he's just doing a lookup for static data, then I'm thinking disk IO is >> faster for him? not sure > > I would think that rolling your own solution would get complicated > enough that it would be easier to just use SQLite or something. If you > wanted to go to the effort, you could probably get something faster, but > if SQLite is fast enough, who cares?
I would concur with this, in general. It may be that, for some very particular situations some specialised storage format is superior, but it's *very* easy to start writing your lean and mean data storage / algorithm / thingy only to run into *exactly* the same issues which the guys who wrote the existing ones have already hit and solved. Problems scaling; concurrency; robustness to error conditions and network / hardware issues &c. And in any case, the usual wisdom applies here: rather than guess which is faster, try it. (There is no "guess": only "try" ;) Using say SQLite (possibly in memory mode) and get some figures. Then do the same with a shelve solution or some prototype of your own devising and see where the gains are. TJG -- http://mail.python.org/mailman/listinfo/python-list
