'Lite' Databases (Re: sqlite3 and dates)

[Mario Figueiredo]

On Thu, 19 Feb 2015 12:26:04 -0800 (PST), rurpy at yahoo.com wrote:
>
>I'll point out that five people in this thread (by my 
>count) have said that Postgresql requires a significant 
>amount of work to setup and use.  Only you and Steven claim
>the opposite. 

Well, I claim the opposite too.

>Or I could have tried as you 
>and Steven suggest to "somehow" package Postgresql in my 
>app installer.  That would have been an even bigger cost 
>in my time with an uncertain outcome.

I don't see how. You said it was just a simple application this
postgres database was serving. So I must assume you aren't talking of
a complex setup that database synchronization or other features that
force a manual setup.

For your purposes, you could just basically backup your data folder
and package postgres with the same configuration files you have in
your current computer.

>None of those 
>costs would have been necessary at all had I developed 
>a self-contained Sqlite app.

The cost would have probably been much higher, depending on your
project. SQLite would have forced you to move all your business logic
into your code, greatly increasing code maintenance, your application
extensibility and its ability to more easily adapt to new business
requirements.

Conversely, if none of this is true concerning your particular
project, then you just chose the wrong tool. Postgres was overkill for
your particular needs and it was a mistake to think you need it to
function just as a shelve on steroids.

>
>Finally keep in mind that if you develop your app using
>Sqlite, it is likely to be far easier to migrate to
>a heavy-duty backend like Postgresql later should you 
>need to than to go in the other direction when you find 
>out you didn't really need Postgresql after all and the 
>cost turned out to be higher than you expected.

Completely not true! For the reasons mentioned above. You are
concentrating too much on the RDBMS aspects and completely forgetting
about the implications in your codebase.

Whether you move from a non distributed model to a client-server
model, or the other way around, your code will suffer major changes.
And even if you decide to keep the business logic in the client layer
(which is a mistake) when moving from SQLite to a client-server RDBMS,
you will still have to deal with a whole new set of issues regarding
the very nature of concurrent access that will essentially force you
to scrap much of your previous code.

>It is bad advise to recommend using Postgresql without 
>regard to the developer's actual needs.

Naturally. But I must say postgres isn't the bad cat you painted in
your post. It's much, much easier to distribute, deploy and manage
than you are suggesting.

For most systems where performance and database synchronization aren't
a requirement, it can be entirely automated, I know, because that's
how we had it set up on three schools where we sold our integrated
management system. I haven't had a maintenance request call in 8
months.

It's only under critical requirements that postgres necessitates a
baby sitter. And those projects don't suffer from lack of competent
administrators.