'Lite' Databases (Re: sqlite3 and dates)

[Mario Figueiredo]

On Wed, 18 Feb 2015 15:32:36 -0800, memilanuk <memilanuk at gmail.com>
wrote:

>
>Is there anything *good* that sits in between the two extremes of SQLite 
>and PostgreSQL?
>
>I've tinkered with MySQL years ago (in conjunction with PHP) and was a 
>little unhappy with some of the things

MariaDB is backwards compatible with MySQL and may answer some of the
shortcomings. It's a much stronger RDBM in my opinion than MySQL and
offers enterprise level features at cost 0.


> PostgreSQL, to me, is orders of magnitude harder to set up and
> maintain, though.

PostgreSQL grows on you. It takes time to mature into a love
relationship, like a complicated girlfriend (or boyfriend, whatever
floats your boat). But once that relationship grows, you will want to
marry with it, have little postgre kids and grow old with it. No other
database stands a chance from that moment on.

It's just too powerful and too feature rich, to ignore. Only Oracle
stands a chance against it, in my humble opinion.

And postgre isn't really that hard to setup and maintain. In fact,
maintenance can be largely scriptable and 'croned' because the postgre
server is so damn stable. Once you familiarize yourself with the
process, you just realize it was easy all the time after all.

I usually think of my relationship with postgre as similar to what I
experienced with Git. At first I was just dumbstruck by the whole
thing and my first reaction was to ignore it and just do version
control as I knew with the tools I knew. But once my brain clicked
into 'Git mode' and I realized its philosophy and its processes, I
immediately recognized the benefits and understood why everyone was
telling me Git was easy to use and highly useful.

>then there is SQLite, which does 99% of what I want it to do other than 
>network use.

SQLite misses some important features that makes it better suited as a
simple datastore, not much unlike shelve. And network use is not one
of them, since you can actually implement concurrent sqlite access by
coding an intermediate layer. Assuming of course we are talking about
a small number of concurrent users.

Stored procedures is perhaps the most obvious missing feature.
Contrary to an opinion I read on the thread that spawned this one, you
really should thrive to put the business logic into the database as
this permits great simplification of your code and much better
adaptability to new requirements. SQLite IS a database. And wants to
be used as a database. So despite agreeing SPs would increase SQLite
footprint, it's undeniable they could be put to good use. Admittedly
these too can be implemented through an intermediate layer. But are
much more complex to code.

Parameterized queries is just a pet peeve of mine that I wish to
include here. SQLite misses it and I miss the fact SQLite misses it.
The less SQL one needs to write in their code, the happier one should
be.