On Fri, Aug 12, 2016 at 11:24 AM, Daevor The Devoted <dollien@gmail.com> wrote:
On Fri, Aug 12, 2016 at 10:58 AM, Andreas Joseph Krogh <andreas@visena.com> wrote:
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.
There is overhead, of course but sometimes it cannot be avoided. In a large scientific programming project I helped with, we were using Perl and DBIx::Class and we had to partition a table because of autovacuum and planner considerations (autovacuum not keeping up on one large table, and partition key dramatically affecting which indexes were useful). You can't just get this to "just work" with an orm. So we added a mapping layer
What you do is create a view, and then add your insert/update/delete logic to triggers which allow the view to actually proxy to the other tables properly. Then you use your view as the base relation your ORM hits. Matt Trout had pointed me to that direction some time earlier and it came in really handy.
The same basic approach can be used to create a mapping layer generally.
But again, if you are primarily worried about development time, then that is more important, usually, than information management as a whole.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
