sqlite3 and dates

[rurpy at yahoo.com]

On 02/18/2015 04:21 AM, Chris Angelico wrote:
> On Wed, Feb 18, 2015 at 10:11 PM, Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:
>> On 18.02.2015 08:05, Chris Angelico wrote:
>>
>>> But if you need more facilities than SQLite3 can offer, maybe it's
>>> time to move up to a full database server, instead of local files.
>>> Switching to PostgreSQL will give you all those kinds of features,
>>> plus a lot of other things that I would have thought pretty basic -
>>> like ALTER TABLE. It was quite a surprise to learn that SQLite3 didn't
>>> support that.
>>
>> I see you're running a lawnmower. Maybe you should switch to a combine
>> harvester. That'll get you extra features like a reciprocating knife
>> cutter bar. I was quite surprised that regular lawnmowers don't support
>> those.
> 
> SQLite3 is fine for something that's basically just a more structured
> version of a flat file. You assume that nobody but you has the file
> open, and you manipulate it just the same as if it were a big fat blob
> of JSON, but thanks to SQLite, you don't have to rewrite the whole
> file every time you make a small change. That's fine.

That's bullshit.  Sqlite offers a lot more than that including
a SQL interface, transactions, referential integrity, constraints 
indexes, triggers and other general relational database features.  

That you would equate that to a JSON blob would indicate either 
a profound ignorance about Sqlite or (more likely) a need to
defend your preference with complete disregard of fact. 

> But it's the
> wrong tool for any job involving multiple users over a network, and
> quite probably the wrong tool for a lot of other jobs too. 

Nobody disputes that nor was that the point.  The point was 
that there are many applications that can benefit from use 
of a database that are NOT distributed multi-user, muilti-tier
applications.  For many of that very large class of applications 
Sqlite is a good (and preferable to Postgresql) solution.

> It's the
> smallest-end piece of software that can truly be called a database. I
> would consider it to be the wrong database for serious accounting
> work, and that's based on the ranting of a majorly-annoyed accountant
> who had to deal with issues in professional systems that had made
> similar choices in back-end selection.

I consider the program I use for my personal accounting program 
to be for very serious use since errors could have very grave
consequences for me.  But a multi-user client-server database 
is emphatically not needed by it.

And I'm sure you're aware that "not for serious use" is a common 
way that C and Java programmers dismiss Python?  So maybe you 
should try a little harder to come up with real arguments and 
not rely on cheap and meaningless labels.

> You're welcome to disagree, but since PostgreSQL doesn't cost any
> money and (on Linux at least; can't speak for other platforms) doesn't
> take significant effort to set up, I will continue to recommend it.

Postgresql costs a *lot* more -- in setup and on-going maintenance.
Not all (or even most) costs are the initial monetary purchase expense.

Its an unmoderated newsgroup so feel free to recommend what you
want.  But counter opinions should be aired so that others a
can judge for themselves whether your recommendations are based 
on facts or on your personal preferences.