Re: Postgres Pain Points 2 ruby / node language drivers - Mailing list pgsql-general
On Fri, Aug 12, 2016 at 10:58 AM, Andreas Joseph Krogh <andreas@visena.com> wrote:
På fredag 12. august 2016 kl. 10:33:19, skrev Chris Travers <chris.travers@gmail.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.
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
Attachment
pgsql-general by date: