RE: Multi- Occurrence Data Structure

From: Larry Ducie

But its EASY to understand SQL - it is a character based scripting
language:
"select mycolumn from mytable where myothercolumn = "This Value". What's
hard to understand there?

Add more than one file and a CASE statement and SQL is as obscure, if not
more obscure, than any other language. I'm sorry, but to my mind the "SQL
is easier to understand than the cycle" argument is a non-starter.

<snip>
I'm not clear on when/why one language is acceptable for "Cycle"
encouragement and another must be considered to be 'obscuring' or
confusing.
</snip>

We encourage it when it is useful and relevant. The cycle and primary
files are not useful to me and SQL is. It is as simple as that.

Yup, that's you. And the fact that I tend to agree for some 98% or so of
the programs I write doesn't make the cycle "obscuring", any more than a
CASE statement in an order-by clause is obscuring.

Before we forget - the RPG cycle was invented to allow accountants to
print
monthly sales reports for their managers without having to "program"
anything. It was nothing more than a 1970's report wizard.

I love this argument. SQL was written primarily for the same purpose: to
get data out of databases. It really wasn't written to be a primary
language for OLTP (otherwise it would have been called STPL <grin>).

Why do we have
all these things? Because a bog-standard RPG program with primary and
secondary files just isn't enough. We added them because we need them.

The same could be said for things like prepared statements and connection
pools and static SQL and query optimizers and CASE statements and UDFs and
CTEs and scrollable cursors. We added all this crap because a bog-standard
SQL processor isn't anywhere near fast enough or powerful enough to handle
the things we do with them.

I think this thread is probably dead now.

Okee dokee. I just wanted to present a different viewpoint.

Joe