Simon, I would agree in other cases, however, in our app, the schema is dynamic and depends on the user data. Normally, we have about 200 tables with two or three columns each, with indexes almost on each table. Queries with lots-of-joins are also constructed dynamically, and we found SQLite to be pretty effective in selecting optimal join algorithm based on ANALYZE results.
Likewise, there are reasons for needing "40 params", or otherwise pass "IN (int array)" in a WHERE clause; for example, to verify that a given set of, say, 40 entities would be returned from a query that returns 100 000 entities -- without running the query itself. (This can be solved by creating a temporary table, inserting entity ids there and joining that table with the query - however, we're looking for a more efficient way.) Thanks! Igor Simon Slavin-3 wrote: > > > On 14 Jul 2010, at 4:17pm, Igor Sereda wrote: > >> For example, where we now have a query >> >> SELECT ...lots-of-joins... WHERE ...lots-of-exprs... AND someColumn IN >> (?,?,?,? ...40 params... ) > > This -- the 'lots-of-joins' and the '40 params' in particular -- suggests > you should be rethinking your schema. You'll probably speed up your > entire system and save a lot of very complicated programming by merging > some tables and/or making some separate columns of a table into a > collection of keyed properties. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://old.nabble.com/binding-an-IN-tp29135222p29165733.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
