sqlite3 and dates

rurpy at yahoo.com rurpy at yahoo.com
Wed Feb 18 23:08:03 EST 2015


On 02/18/2015 04:07 PM, Steven D'Aprano wrote:
> rurpy at yahoo.com wrote:
>> On 02/18/2015 01:14 PM, Ben Finney wrote:
>>> Johannes Bauer <dfnsonfsduifb at gmx.de> writes:
>>>> 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.
>>>
>>> Chris has pointed out one flaw in this analogy; I'll address another.
>>>
>>> A feature like 'ALTER TABLE' is not equivalent to a "reciprocating knife
>>> cutter bar". I'm in agreement that it is a pretty basic SQL feature, and
>>> it doesn't appear to conflict with the narrow focus that we all agree is
>>> appropriate for SQLite.
>>
>> No, you and Chris are way off base and Johannes is correct.
>> He was pointing out that there are many applications that can
>> benefit from a database and a full-blown, bells and whistles
>> solution like Postgresql is often overkill in that (very common)
>> case.  His analogy is quite apt and I wish I'd thought of it.
> 
> 
> I'm not seeing that at all. Chris explicitly proceeded his comments with the
> condition "if you need more facilities than SQLite3 can offer".

Right.  And did so in a context where there the facility 
presumed not to be offered was getting a date back from Sqlite.
Common sense should tell anyone that it is very improbable 
that there is no way to get a date out of a sqlite database.
Chris' "solution" to that problem?  Switch to Postgresql.
That was the context for Johannes' analogy.

> Johannes'
> analogy ignores that and consequently mocks the very idea that anyone might
> need more than a regular lawmower -- even a farmer with a thousand acres of
> wheat to be harvested.

The analogy works precisely because farmers with a thousand 
acres of wheat to be harvested need reciprocating knife 
cutter bars.  In the same way people dealing with terabytes 
of data, concurrent updates, enterprise scale data and 
applications need a Postregsql.  People mowing their lawns 
do not.  People without needs for the things that client server 
database do well, whose problem is not immediately being able
to figure out how to get a date, do not.  (Did you really need 
that explained to you?)

If you didn't interpret it the way I did (and the way I presume
Johannes meant it) then, well, you didn't interpret it the same.
Your interpretation (especially given your penchant for sophistry) 
are not my problem.  I am quite happy to let anyone reading make 
their own evaluation.

> Johannes' subsequent posts are more nuanced about Sqlite filling a niche and
> not being suitable for everything, but the analogy you're supporting
> doesn't. It's an amusing quip, quite funny, but like most quips, lacks
> nuance and misrepresents Chris' original position.

All analogies are imperfect and thus make easy targets.  Shrug.
 
>[...]



More information about the Python-list mailing list