Pavel Ivanov schreef: >> Currently this means adding >> the new columns to my C-structures, writing access functions, and >> recompiling. I don't want to do that, because this means my appl *must* >> be replaced on every database change, and I'd like to be able to >> run different versions of it in the wild. I was hoping to make it >> more dynamic and adaptive to database layout changes. > > Sorry, Ron, but I don't get it. You're saying that adding more columns > means adding more fields into your structure and making your > application to know about those fields, and that means you need to > recompile and it's a bad thing. But if you're working with SQLite's > in-memory database then you have to create all tables in that database > at startup, so you need an SQL statement in your application > containing all columns you use, so again adding a column you need to > recompile, right? Or if you generate your CREATE TABLE statement > dynamically from postgresql then how does your code know about new > fields added? How does it work with it? Are your newly added columns > used only from sql coming directly from clients? > Maybe you just need to re-think your database schema so that you need > only one select statement per network request and so your requirements > to sql engine speed would be lowered by the order of magnitude? >
Pavel, You are right, and I'll look into rewriting a bigger part of our application. Thanks, Ron > Pavel > > On Sun, Oct 18, 2009 at 2:23 PM, Ron Arts <r...@arts-betel.org> wrote: >> P Kishor schreef: >>> On Sun, Oct 18, 2009 at 10:37 AM, Ron Arts <r...@arts-betel.org> wrote: >>>> Very true Simon, >>>> >>>> this has been the fastest way so far and I can do around >>>> 350000 selects/second this way, using prepared statements >>>> (on my machine at least), but I need more speed. >>>> >>>> That's why I want to skip the SQL processing entirely >>>> and write a C function that reaches directly into the >>>> internal memory structures to gets my record from there. >>> I might have missed the discussion, but... why don't you ditch SQLite >>> and use something like Berkeley DB? Sounds to me you need a hash db >>> instead of an rdbms, especially since you have no need for SQL. >>> >> Well, that's what I use at the moment (I use glib2 g_hash_table()), >> but now the requirement to accept SQL queries for that database >> has come up. And I don't want to write my own SQL parser.. >> >> Next I tried to add a virtual table driver to SQLite for my database. >> That worked, but because the application is evolving, columns >> get added/changed on a regular basis. Currently this means adding >> the new columns to my C-structures, writing access functions, and >> recompiling. I don't want to do that, because this means my appl *must* >> be replaced on every database change, and I'd like to be able to >> run different versions of it in the wild. I was hoping to make it >> more dynamic and adaptive to database layout changes. >> >> Thanks, >> Ron >> >> >>>> thanks, >>>> Ron >>>> >>>> Simon Slavin schreef: >>>>> On 18 Oct 2009, at 8:37am, Ron Arts wrote: >>>>> >>>>>> Is there a way to bypass the virtual machine altogether and reach >>>>>> directly >>>>>> into the btree and just retrieve one record by it's oid (primary >>>>>> integer key), >>>>>> and return it in a form that would allow taking out the column >>>>>> values by name? >>>>> The primary integer key column can always be referred to as the >>>>> special name ROWID, even if you have assigned it a column name of your >>>>> own. So you can do >>>>> >>>>> SELECT ROWID,myCol1,myCol2 FROM myTable >>>>> >>>>> as long as you don't explicitly declare a primary integer key column >>>>> and then change the values in it. >>>>> >>>>> Simon. >>> >>> >>> >>> >> _______________________________________________ >> 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
