Re: Postgres Pain Points 2 ruby / node language drivers

På fredag 12. august 2016 kl. 10:33:19, skrev Chris Travers <
chris(dot)travers(at)gmail(dot)com <mailto:chris(dot)travers(at)gmail(dot)com>>:
    On Fri, Aug 12, 2016 at 9:59 AM, Andreas Joseph Krogh <andreas(at)visena(dot)com
<mailto:andreas(at)visena(dot)com>> wrote: På fredag 12. august 2016 kl. 05:27:42,
skrev Chris Travers <chris(dot)travers(at)gmail(dot)com <mailto:chris(dot)travers(at)gmail(dot)com>>:
    On Thu, Aug 11, 2016 at 10:20 PM, Andreas Joseph Krogh <andreas(at)visena(dot)com
<mailto:andreas(at)visena(dot)com>> wrote: På torsdag 11. august 2016 kl. 19:13:08,
skrev support-tiger <support(at)tigernassau(dot)com <mailto: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.

 
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.
 
The problems I mention above occur when doing CRUD via an ORM (at least all
ORMs I have worked with).  The fundamental problem is that ORMs make for bad
data management in most cases because *either* you structure your database
table structures around your object model of your application *or* you add
complexity of a logical level structured for your application.
 
But either way, the database has to have intimate familiarity with the
internals of the applications using it.  And there isn't an easy way around
this.

 
If you don't like your domain-model to be very close to your physical
DB-model, there's nothing preventing you from having a persistence-model, using
the ORM, and map that to/from your domain-model. However, I don't see any of
these challenges getting easier by throwing the ORM out and having the
developers handling everything themselves using SQL directly.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
www.visena.com <https://www.visena.com>
<https://www.visena.com>