From: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres Pain Points 2 ruby / node language drivers |
Date: | 2016-08-12 09:30:07 |
Message-ID: | VisenaEmail.cd.e900b16aef681b2b.1567e138a34@tc7-visena |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
På fredag 12. august 2016 kl. 11:24:16, skrev Daevor The Devoted <
dollien(at)gmail(dot)com <mailto:dollien(at)gmail(dot)com>>:
[snip] 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.
Could you elaborate on this method? Or direct me to docs describing it in more
detail? I'm quite interested in this approach, but would like to see what
amount of overhead (development and maintenance) this might result in.
I'm not in favor of this method myself as, IMO, it adds an unnecessary
mapping-layer which just slows down development. But it might make
sense depending on how much control you have on your DB, domain-model, code,
developers etc.
I don't have any pointers describing this separation tho, try asking Mr.
Google, that's what I'd do.
-- 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>
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2016-08-12 09:32:43 | Re: Postgres Pain Points 2 ruby / node language drivers |
Previous Message | Daevor The Devoted | 2016-08-12 09:24:16 | Re: Postgres Pain Points 2 ruby / node language drivers |