Re: DB2 connect server

I like the concept of ORMs, where an OOP language can more easily (I'm
told) fetch a composite business object defined in the ORM.

I'm interested to know if defining a composite business object in the ORM
is really that much different or easier than defining SQL views or SQL
procedures designed to return business objects.

I don't think that configuring an ORM object has as much capability as can
be performed by an expert in SQL, because I've worked with ORM / OOP
developers that ask for assistance with SQL when the capabilities of their
ORM falls short, and they are forced to step outside the ORM and use SQL.
Use of ORM isn't a 100% replacement for SQL.

I'm also curious, from those familiar with consuming an ORM object in an
OOP, if that consumption is truly that much easier than calling an SQL
stored procedure that returns, if needed, multiple result sets that
represent a composite business object.

ORMs aren't devoid of potential for abuse. I've seen systems where the ORM
is configured to apply data rules in the ORM object configuration, that
aren't defined in the database, and then the same OOP system consuming the
ORM object creates data that does not conform with the ORM only defined
data rules. Net result is the database accepts the invalid data written by
the OOP system, but sometime down the road (could be days or weeks) the OOP
system chokes when the ORM layer, at the request of the OOP system, reads
that invalid data. Moral of the story is, in my opinion, those rules belong
in the database, not tucked away in a higher layer that isn't guaranteed to
enforce them. The ORM, and the UI, should pull all the data rules from the
database so they are centralized in a single place.

Mike

date: Fri, 22 Jan 2016 13:03:40 -0500

from: John Yeung <gallium.arsenide@xxxxxxxxx>
subject: Re: DB2 connect server

On Fri, Jan 22, 2016 at 12:30 PM, Justin Dearing <zippy1981@xxxxxxxxx>
wrote:

On Fri, Jan 22, 2016 at 11:32 AM Matt Olson <Matt.Olson@xxxxxxxx> wrote:

We have been using the ADO .NET driver for years, but writing SQL is a
development pit we would like to try start digging ourselves out of.

I don' get this thinking at all. [...] why not just write SQL. It doesn't
take a lot longer in programmer time. ORMs don't generate better SQL than
the average programmer. SQL is not assembly. Its readable and writable by
mortals.

It's not about whether people write better SQL than ORMs. It's about
the way ORMs potentially allow you to think about the problem using a
more natural abstraction than tables.