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.

Basically, the argument in favor of ORMs over plain SQL is analogous
to the argument in favor of object-oriented programming over
procedural imperative programming. Yeah, languages like Pascal and C
are higher-level than assembly. They are indeed very readable and
writable by humans. But some problems (not necessarily all problems)
are more naturally modeled using an object paradigm. And indeed people
started to write the beginnings of their own, ad-hoc OOP constructs in
languages like Pascal and C (using structs, unions, pointers, etc.).

Now, I'm sure you're thinking "but SQL is WAY higher level than Pascal
and C!". That's true, it absolutely is. But it makes you fundamentally
think in terms of tables. Rows and columns. Joins. This is not too
much different than thinking in terms of two-dimensional arrays. Excel
spreadsheets. VLOOKUPs. ORMs provide a framework for modeling your
data as objects in the way Smalltalk, Java, Python, or Ruby let you
model your data as objects.

So ORMs are not for everyone, and they don't always provide a lot of
value for every problem. But for some people and some problems, they
provide a significant value indeed. Especially if most of the
application is being written using an OOP style (and properly
leveraging the benefits that confers), ORM lets the data access be
seamlessly integrated. No "embedded SQL", just write everything in
(say) Java or C# or Python.

John Y.