From: Tim Cross <theophilusx@gmail.com>
To: Peter J. Holzer <hjp-pgsql@hjp.at>
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Rationale for aversion to the central database?
Date: Tue, 10 Apr 2018 08:16:52 +1000
Message-ID: <87d0z86n57.fsf@gmail.com> (raw)
In-Reply-To: <20180409134451.7cag3c7427zncayl@hjp.at>
References: <7e56cc47-ae9c-43ee-9984-77df3a485d2e@Spark>
<20180409134451.7cag3c7427zncayl@hjp.at>
Peter J. Holzer <hjp-pgsql@hjp.at> writes:
> In my applications I use SQL heavily. RDBMs are good at processing
> queries, so use them for that. If all you want is a key-value store,
> don't use PostgreSQL. I'm not very fond of ORMs. I know what I want to
> do and can express it in SQL. An ORM makes me translate that into a
> different (and usually inferior) query language, which is then
> translated back into SQL. That doesn't make things easier for me.
>
Could not agree more! My experience has been that ORMs just get in the
way. Worse yet, when I've investigated performance problems raised by
developers, I've often found it is due to the ORM layer, which is unable
to map more complex queries efficiently.
The only 'layer' I've ever used which I liked was HugSQL. I quite liked
this approach as you write the queries in SQL and these get exposed to
the application layer as high level functions, so gives a nice clean interface.
>
> I come from Oracle, not MySQL, But I have also used MySQL, and I guess
> the very wide gap in capabilities between Oracle and MySQL made me
> cautious about putting too much into the database. There is also the
> expectation that you should be able to use a different database engine
> (SQL is a standard, right?) just like you should be able to use a
> different C compiler, but in practice that never works. And of course I
> wasn't very impressed with PL/SQL. (PostgreSQL gives you a much wider
> range of languages for stored procedures than Oracle, but PL/PerlU still
> isn't quite the same as Perl (And I suspect it's the same for Python).
>
> hp
Again, totally agree. Nice in theory and reminds me of the 'write once,
run everywhere' dream. Very few of the places I've worked have actually
maintained cross database functionality for long, if at all. The problem
is that while SQL may have a standard, how that standard is implemented
is very different. When I have worked at places which tried to be
database neutral, they inevitably give up as they find that in the end,
they needed to maintain separate SQL or have separate database
maintenance teams anyway. You will only get seamless SQL across
different databases if your SQL is very basic, in which case, you
probably don't need a full blown RDMS anyway. Most of the time, your
choice of database will be dictated by your dominate platform in the
market your application targets.
--
Tim Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: theophilusx@gmail.com, hjp-pgsql@hjp.at, pgsql-general@lists.postgresql.org
Subject: Re: Rationale for aversion to the central database?
In-Reply-To: <87d0z86n57.fsf@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox