Just a personal observation from the peanut gallery (my uninformed opinion). I like SQLite pretty much as is. When I use it, I want reliable (ACID), fast, and SQL compliant. I use SQLite more like an "embeded" or "single user" SQL engine. I don't use it for a really hairy data base application. Yes, I know that it can indeed do that work. But if I need multi-system, multi-user, redundant RDMS, I use PostgreSQL. It is "heavy" but works well for me. I don't want to replace PostgreSQL with SQLite, in general. Again, I know that there are massive SQLite DBs out there. But are they being hit by 100+ users concurrently? I truly don't know.
But if it is up for a vote, I vote "stay lean". On Sun, Nov 10, 2013 at 9:09 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 10 Nov 2013, at 12:05pm, Raheel Gupta <raheel...@gmail.com> wrote: > > >>> I can't think of any other single feature that would remove the "lite" > > > > I am not a database expert. If you say so, it must be the case. > > But if there is a way to implement concurrent writers in SQLite > maintaining > > the "lite" in SQLite, I would be the most happiest person here :) > > The main reason you seem to prefer SQLite to other databases is that it's > faster. Adding row-level locking to SQLite would slow it down a lot. As a > very simplified explanation, for one SELECT instead of > > try to lock the database > check to see that the lock on the database is yours > FOR EACH ROW: > figure out where the row's data is > read the data > unlock the database > > you have to do > > FOR EACH ROW: > figure out where the row's data is > try to lock the row > check to see that the lock on the row is yours > read the data > release the row > > If your SELECT returns 10 rows you end up doing 50 operations instead of > 23. Which would mean that SQLite was half the speed, and no longer had any > advantages for you, so you would use something else. > > Locking is the single hardest thing to get right when writing a DBMS. > SQLite gets a lot of its tininess and speed by implementing the simplest > fastest method of locking possible. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
