Thanks for the input. Like everything else in life there are trade-offs. I guess that the real question originates because the time it takes to query the data seems a lot faster when I use a simplier select statement. As I add more restrictions on the where-clause it tends to slow down. I realize that this is due to my indexes, but can't add a lot of indexes because it slows down the insert speed which is more important than the query speed. There is only one instance where this functionality would be handy anyway. In 48 other instances the ability to query the database is imperative.
Having said that SQLite is light-years faster than other databases I have used for this project. Good job to everyone who helps to support it. Keep up the good work! On 4/21/2010 3:28 PM, P Kishor wrote: > On Wed, Apr 21, 2010 at 1:19 PM, Nathan Biggs<nbi...@mycfs.com> wrote: > >> Is there a way to read the values of a table directly without building >> and executing a query. I have a function that has predefined memory >> (counters) and increments them if the data in the record matches a hard >> coded value. >> >> Since this is hard-coded, I thought it might perform much without all of >> the memory allocations/de-allocations associated with the query engine. >> >> > Others have already responded, but in questions like this, my standard > response is... measure. If you think it might, it is time to measure, > do a test. Only you can do a test that is meaningful to you. Of > course, you can and should ask for ways to make your queries more > efficient, but in the end, a test on your hardware, in your > environment, is the only thing that matters. > > That said, why choose a sql database, and then want to bypass its sql > engine to access the data directly? Even if you could, why would you? > Why not just begin with a more appropriate data store in the first > place? If you don't need sql, just go ahead and choose a key-value > db... Berkeley DB is free for the taking... try Tokyo Cabinet. I am > sure there are others. > > > >> Thanks for your help. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
