× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.