On Sun, Jun 14, 2015 at 1:19 PM, Richard Hipp <drh at sqlite.org> wrote: > On 6/14/15, Scott Hess <shess at google.com> wrote: >> SQLite essentially gives you a set of >> b-trees with syntactic sugar over them, > > SQL (and I speak in general terms here, not just of SQLite) provides > way more than syntactic sugar over b-trees. The syntactic sugar over > b-trees part is the *least* of the many advantages of SQL. Other more > important features include:
To be clear, what I mean by this is that if you have a set of operations which you could do in your native language, and you decide to instead push them into SQLite, and you are concerned about performance and memory use, then it really behooves you to be able to describe how to accomplish those operations using SQLite's basic data structures. Many developers build their SQL assumptions in an environment with a memory-constrained app server calling out to a database server running on the beefiest machine their ops people can acquire. The set of things-that-are-appropriate are going to be different in an environment where "Map a multi-gigabyte index into memory" is a valid approach. In case it isn't clear from my post (I have a bit of a head cold going on, so I probably shouldn't be writing posts on public mailing lists), IMHO SQLite has done a really solid job covering the bases for the area of operations it has staked out, and has done a good job of not adding features inappropriate to those goals. It's just that IMHO developers often make dubious assumptions about what _else_ SQLite can do. -scott
