Re: Postgres Pain Points 2 ruby / node language drivers

On Fri, Aug 12, 2016 at 10:58 AM, Andreas Joseph Krogh <andreas(at)visena(dot)com>
wrote:

> På fredag 12. august 2016 kl. 10:33:19, skrev Chris Travers <
> chris(dot)travers(at)gmail(dot)com>:
>
>
>
>
>>
>> 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.
>

My preference is stored procedures plus service locators, to be honest. It
enables a degree of loose coupling and even dynamic discovery that ORMs are
generally not well suited to.

But I think the difference may be bigger. ORMs make sense when you want a
database for your application. They break down badly when you want an
application for your database. Usually I tend to want the latter.

>
> --
> *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