On Mon, Sep 19, 2016 at 4:56 PM, James K. Lowden <jklow...@schemamania.org> wrote:
> On Wed, 14 Sep 2016 16:27:37 +0530 > > But I agree with Teg: SQLite is providing you with transactions you > don't need, and puts an interpreted language exactly where you don't > want it: in a performance-critical spot. The C++ standard library has > all the bits you need, and is almost as convenient to use. > > You have only one table, and probably just a few simple queries. > std::set gives you lower_bound and upper_bound. Hand those two > iterators to std::accumulate, and you have GROUP BY. Call that for 5 > prices. Not very much code, and I bet 100x faster than SQL. If more > than one thread is updating the table, obviously protect your set with > a mutex. > In addition to James' excellent answer, I'd add that using C++/STL containers doesn't preclude you from having SQL on top of them, thanks to SQLite's virtual tables. For example, FWIW, I extensively use Boost's Multi-Index containers, which are like statically indexed tables (you decide what indexes you want, at compile time), and layer read-only virtual tables on top, properly exposing the static indexes to SQLite's query planner (via xBestIndex). That way you can use C++ when you want, but can still benefit for all the flexibility of SQL, which happens to read even faster than SQLite's in-memory DBs. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
