Re: SQL vs. traditional I/O?

Ok... let's not pick a application it can't handle
very well, since that wouldn't be "real world" ???

In my original message, I stated that I though SQL
was probably quite good in "certain" applications.

I think some people lose sight of what SQL was designed
to do(including IBM). A query language that does more
than query is being asked to do too much.

Somebody at IBM decided that SQL was very cutting edge
and that it should be the premier way to handle I/O.

They even went to the trouble of offering SQL as a
"free tool" in many system configs. I think they still
do. Some people jumped on board, many "did not" after
seeing what I describe as "terrible performance".

In my opinion, SQL works well in a very controlled
situation where the developer has a VERY full understanding
of what SQL can and can't do. Many new programmers are
using SQL as crutch, since they have no idea of how the
problem might be handled in some other way. This lack of
understanding probably contributes to the poor performance.

I don't say that SQL is right or wrong but it's reputation
has not been too good in the past. That was my experience.

One more thing to fan the flames:

Ever wondered why IBM would push a product that is known
to consume huge blocks of resources and even cause upgrades
to the system after a large scale implementation ???

Walden H. Leverich wrote:

Joe,

You're doing row-at-a-time processing, you're just using SQL to do it.