On Wed, 18 Feb 2015 15:32:36 -0800, memilanuk <memila...@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. -- https://mail.python.org/mailman/listinfo/python-list
