'Lite' Databases (Re: sqlite3 and dates)

[rurpy at yahoo.com]

On Wednesday, February 18, 2015 at 10:39:04 PM UTC-7, Ethan Furman wrote:
> On 02/18/2015 09:26 PM, memilanuk wrote:
> > On 02/18/2015 09:16 PM, Ben Finney wrote:
> >> memilanuk <memilanuk at gmail.com> writes:
> >>
> >>> In the past I've been waffling back and forth between a desktop
> >>> client/server setup, or a web-based interface with everything on one
> >>> computer. At this point I'm leaning toward the latter.
> >>
> >> So, it's been many exchanges back and forth, and you still aren't
> >> telling us what specific needs you have that SQLite can't provide. At
> >> this point I'm just going to have to wait until you can lay out the
> >> specifics.
> >>
> > 
> > Okay, let me put it like this:  if I set up a web interface using Flask for the front-end, and SQLite as the backend DB,
> > running from a PC/laptop, with anywhere from 1 to 10 people doing data entry from other devices (laptops, desktops,
> > tablets, etc.) at roughly the same time, is SQLite going to be 'concurrent' enough?
> 
> Well, having zero experience with SQLite, but having read the docs just today [snip snide remark] -- I think you'll be
> fine with SQLite under those conditions.  :)

I too agree with this (with a similar caveat -- I've only 
used Sqlite for playing around and have no real experience
using it in real-world applications).  

Another thing to keep in mind is if you do need find you
need a more heavy duty backend, it will be easier to migrate
from Sqlite to Postgresql (or whatever) [*] than to go the 
other way should you later find Postgresl too heavy-weight 
and costly.

----
[*] Unless you are very careful to use only features in 
Postgresql that you've determined can be easily migrated 
back to Sqlite.  In practice very few people have the 
strength of character required to do this. :-)