Re^3: Where to put an application database?

boftx:

A lot of databases handle the permissions issue by having a separate server process that actually does the database work, and all clients just submit requests to that process to get the work done.

SQLite, though, doesn't use a server process. Instead every client has a copy of the code to perform database updates. In that case, the file will need to be modifiable by everyone if you want them to be able to make any changes.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Comment on Re^3: Where to put an application database?

Replies are listed 'Best First'.
Re^4: Where to put an application database? by boftx (Deacon) on Oct 18, 2014 at 04:33 UTC
OUCH! You must always remember that the primary goal is to *drain the swamp* even when you are hip-deep in alligators.	[reply]
Re^5: Where to put an application database? by erix (Prior) on Oct 18, 2014 at 05:43 UTC
OUCH! Yeah. As its creator, Richard Hipp, talking at PGcon 2014, said: SQLite is not a replacement for PostgreSQL. SQLite is a replacement for fopen(). `[2]` The SQLite docs contain a page called "Appropriate Uses for SQLite" `[1]`, which says: SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time. For many situations, this is not a problem. Each application does its database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require more concurrency, and those applications may need to seek a different solution. Wonderful tool as SQLite is: when compared with full-fledged RDBMS's it has some pretty heavy limitations. It's best thought of as a 1-person database (and the possibility for embeddedness is of course enormously useful (browsers, phones)). `[1]` http://sqlite.org/whentouse.html `[2]` Hipp's keynote at PGcon 2014 `[2]` youtube version of Hipp's talk	[reply] [d/l] [select]