Document/Object DBs are kind of the solution for that, however, they still need to be managed.
Grow a beard and become "full-stack". On Fri, Sep 16, 2016 at 11:56 AM, Greg Keogh <gfke...@gmail.com> wrote: > The people who think that ORMs are a good idea have a code-centric view of >> the world. >> > > Stored procs! > > Here's the black hole of the argument. To me it's a simple reductionist > problem... Clean-shaven code-centric people write real-world apps. Beardy > DBAs design databases. Coders need databases. Databases are unlikely to > have a structure that suits coders. What can bridge the "impedance" gap? > Something has to. > > It doesn't matter how much you like stored procs, you still have to get > stuff in and out of them across the gap to the coder's classes. How do > procs help? Are you proposing that more business logic be moved into procs? > If so, that way lies madness, as you can't easily integrate proc code into > source control, testing, versioning, builds, etc. I've seen whole apps > written in T-SQL, and it's quite frightening. > > Coders need ORMs, heavy or light. I've only used 2 this century, but they > simplify and reduce code by a staggering amount. The benefits far outweigh > the deficits. > > I was just discussing this with a colleague and we have made a casual pact > that in future apps we will try to meet more halfway across the "gap". He > will write procs that aggregate and deep load joined data for complex > queries, then my code on the ORM side will query what the proc assembles. > We haven't worked out the details of this plan, but I think it lets each > part do what they are best at. The procs will assemble and shred data out > of tables and the code will work with business objects. > > *Greg* >
