Re: Postgres Pain Points 2 ruby / node language drivers - Mailing list pgsql-general

From Andreas Joseph Krogh
Subject Re: Postgres Pain Points 2 ruby / node language drivers
Date
Msg-id VisenaEmail.c2.f6b07dd2d9ad0af.1567d75cc1b@tc7-visena
Whole thread Raw
In response to Re: Postgres Pain Points 2 ruby / node language drivers  (Chris Travers <chris.travers@gmail.com>)
Responses Re: Postgres Pain Points 2 ruby / node language drivers  (Chris Travers <chris.travers@gmail.com>)
List pgsql-general
På fredag 12. august 2016 kl. 05:27:42, skrev Chris Travers <chris.travers@gmail.com>:
 
 
On Thu, Aug 11, 2016 at 10:20 PM, Andreas Joseph Krogh <andreas@visena.com> wrote:
På torsdag 11. august 2016 kl. 19:13:08, skrev support-tiger <support@tigernassau.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.
 
I don't understand why people bashing ORMs seem to think that once you have an ORM in you project you have to use it for everything. Of course, the ORM doesn't free you from using SQL directly where appropriate. IMO ORMs are best using for CRUD, but not for reporting or batch-processing. In a large project you have both, so combining is, IMO, the best.
 
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.
 
I don't believe for a second that having an ORM in a project relieves the developers from knowing SQL.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 
Attachment

pgsql-general by date:

Previous
From: James Sewell
Date:
Subject: Standby crash
Next
From: Chris Travers
Date:
Subject: Re: Postgres Pain Points 2 ruby / node language drivers