Re: Postgres Pain Points 2 ruby / node language drivers

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Andreas Joseph Krogh <andreas(at)visena(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres Pain Points 2 ruby / node language drivers
Date: 2016-08-12 03:27:42
Message-ID: CAKt_ZfvBHD6hi+0gF+L=goqOxQy4K+tXV3DZx904K+huALuiOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Aug 11, 2016 at 10:20 PM, Andreas Joseph Krogh <andreas(at)visena(dot)com>
wrote:

> På torsdag 11. august 2016 kl. 19:13:08, skrev support-tiger <
> support(at)tigernassau(dot)com>:
>
> I cannot not comment on this. Saying that ORM seems dumb, and working with
> PG using ORM does not fly, is a very good recipe for not being taken
> seriously.
>

And yet everyone I have talked to understands that ORMs are pretty
problematic as a concept. They make some things easy but they have some
pretty massive downsides. ORMs, it is true, do solve some problems, but
they usually create many more in the process. The reason is that as much
as relations look like collections of objects, they are best organized
along very different principles. While we break down our tables based on
functional dependencies between data values, we break down our object
models based on how we can encapsulate state changes behind consistent
interfaces. The latter is dependent on use, while the former far less so.

Of course you *can* use them well. I remember talking about this with one
author or a major ORM and he said that on thing he often does is create
views with triggers and then use the ORM against those. This solves the
problem above very well. But it still leaves the fact that the database
and the application have to share an implicit understanding of an object
model and keeping that in sync as the project grows can be troublesome.

But once you have a non-trivial project, the promise that ORMs are often
sold on ('you don't have to know SQL') evaporates and you find that you
have to know SQL and the ORM well to get half-way decent performance.

> Of course you can make an ORM hose your DB, but any developer could just
> as easily write SQL which does the same. Also, remember that PG is based on
> volunteer effort and if drivers for some languages are more mature and
> better supported than others, that's because core-pg-developers or someone
> in "the inner circle", or someone else, has use for them. Just because
> language X or framework Y popus up doesn't mean the PG-project should
> maintain drivers for them or support them.
>

Agreed on this.

>
> So - yes, it would be great if all the drivers for all languages would be
> made as reliable and clearly documented as the most supported ones.
>
> --
> *Andreas Joseph Krogh*
> CTO / Partner - Visena AS
> Mobile: +47 909 56 963
> andreas(at)visena(dot)com
> www.visena.com
> <https://www.visena.com>
>
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message hari.prasath 2016-08-12 04:31:38 Re: Jsonb extraction very slow
Previous Message Hannes Erven 2016-08-11 22:53:55 Re: How to parse xml containing optional elements