sqlite3 and dates

[Chris Angelico]

On Wed, Feb 18, 2015 at 6:49 PM, Frank Millman <frank at chagford.com> wrote:
> My accounting software supports three databases - MS Sql Server, PostgreSQL,
> and sqlite3.
>
> sqlite3 is not suitable for 'heavy-duty' applications, but it is ideal for
> demos and one-man businesses. Anyone can try out my software so long as they
> have python installed. They do not have to set up a database.

I wouldn't trust sqlite3 with my accounting... but then, I'm becoming
more and more disillusioned with most full-scale accounting packages,
too. I'm seriously looking toward a git-managed directory of text
files as being the accounting package of the future; a few pre-commit
hooks (and/or pre-receive if you want to have a central repo that
people push to) to check file formats and stuff; and then some scripts
that do maintenance and reporting (eg updating inventory quantities
when you mark an invoice as completed). I want to see a big company
work this way... it's clearly not a problem for a one-man operation,
as I've been doing exactly that for some time (with very few scripts),
and we do know that git scales to global operations just fine, but
will it actually work? Inquiring minds must know!

But anyway, I wouldn't push people onto sqlite3 for anything serious,
mainly because it sucks at concurrency, secondarily because it lacks a
number of common features. I'd push people to PostgreSQL.

> sqlite3 does support ALTER TABLE, but with limited functionality. I think
> all you can do is add a column.

Ah, true. Minor support for altering tables, not quite none. But
still, there's a lot of limitations that will bite you badly any time
you try to migrate a schema using anything other than the brute-force
"create entire new database and import the content".

ChrisA