On 4/29/08, Scott Baker <[EMAIL PROTECTED]> wrote: > I'm curious about the speed trade off between a full table scan and just a > flat file search... Say I have a database with 20000 records in it. If I do > a query like: > > SELECT foo FROM table WHERE bar LIKE '%glaven%'; > > That will be a full text scan across the table. Would that be any faster > than just a regexp against a flat text file? Obviously you get the > advantages of SQL were it in a DB, versus a flat file. What other trade > offs are there? > > My experience the above, is that in SQLITE it's still incredibly fast.
Every now and then we get questions about "will <such and such> be fast or <that and that> be faster." The only definitive way to find out is to benchmark, and the poser of the question is in a much better position to answer than anyone else. 20,000 records means nothing at all... is it 20,000 records aka rows of what? How big is the value of bar? Of course, in SQLite there is no column width concept, so one could stuff in a 10,000 words novel in a column of a row and drastically change the result. That said, my sense is that probably grep against a 20K word file would be faster than SQLite, but again, I am pulling that sense out of thin air. I am too lazy to find a 20K file, grep against it for a pattern, then make a table out of it, and SQL search against it using SQLite. The definitive answer is only to be found, however, by benchmarking. > > > -- > Scott Baker - Canby Telcom > RHCE - System Administrator - 503.266.8253 > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
