Re: Creating XML document via SQL - Db2 for i 7.2 -- RPG400-L

And if you write an app in javascript/node as backend you are very long way
from
the database and since SQL is considered as a major performance bottleneck
you
keep your SQL as simple as possible and - if possible - you move
referential tables
into "in storage" NOSQL objects that will give you approx. 1.2 mio random
reads a
second.

On Sat, Mar 10, 2018 at 11:27 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Let me refrace your last remark to "the further you are away from the
database,
the less SQL you should use" ;-)

On Sat, Mar 10, 2018 at 11:07 PM, Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:

Hi Henrik,

I've done a lot of work with SQL and hierarchical data. Between recursive
SQL and the hierarchical query capabilities, plus the XML and JSON
functions in SQL for working with those types of hierarchical data, SQL
can
be a very productive tool to work with hierarchical data. I can process
hierarchical data using SQL in much fewer lines of code than I could in
RPG, for example.

NOSQL originally meant "non-SQL", but has really morphed into meaning "not
only SQL". Many SQL front ends have been built to query and analyze data
in NOSQL / HADOOP style databases: Apache Hive, Apache Phoenix, Apache
Sqoop, BigSQL, Lingual, Cloudera Impala, Google Cloud Spanner, Presto,
CitusDB, InfiniDB, Hadapt, Jethro, HAWQ, among others.

The trend in recent years has been to build more SQL tools over NOSQL +
HADOOP, not less. The reason for this simple => improve productivity. SQL
eliminates a huge amount of the glue code necessary to fetch a set of data
from a NOSQL / HADOOP database. Even Google developers were complaining
about the lack of SQL in their earlier HADOOP application implementations.

There are limitations with how you can structure SQL, but I never limit
myself to only a single statement when I provide SQL-only solutions. I
use
multiple statements all the time, and when you throw in scalar and table
functions (in particular), procedures, temporary tables, global variables,
views, triggers, and external calls to external objects, there are not
many
things you can't do in SQL. One thing SQL isn't postured to do, is deal
with a user interface. You have to exit SQL to externally call other
languages that have direct capability to talk to a user interface (SQL =>
RPG => DSPF for example).

I wouldn't attempt to create a middle tier business rules layer that only
used SQL, but SQL can certainly play a big role in such a layer in
reducing
code volume. Limiting a solution to only a single language is risky,
inflexible, and less productive.

Assuming you're structuring an application in 3 or more tiers, imo, the
closer you are to the database (e.g. data tier), the more SQL should be
used. The middle tier should use less SQL than the data tier. A front end
tier (user interface) should use even less SQL.

Mike

On Sat, Mar 10, 2018 at 9:34 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

IMHO SQL is a Structured Query Language in a syntax specialized to

process

relational data structures to create an intermediate result set

extracted

from a RDBMS. It has never been intended to process Hierarchical Data
Structures and/or NOSQL DB’s and trying to do so will eventual bring one
into a dead end.

It is a “one statement language” and as so it is nearly impossible to
structure the code into sections that is only processed based on complex
calculated values and rules (BL) especially if the BL depends on partial
results from the processing itself mixed with perhaps changing values

from

the environment outside the statement itself.

On Sat, Mar 10, 2018 at 4:41 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

"And by the way, I don't think likening SQL to OOP is a great way to
entice Jon. He's been known to have his differences with OOP as well.

;)"

Only when it is pushed as the solution to all computer problems John.

And I don't really have "differences" with it - but I have frankly
admitted that after many, many years of procedural programming that it
remains hard for my ancient brain to adapt to it.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 9, 2018, at 11:57 PM, John Yeung <gallium.arsenide@xxxxxxxxx

wrote:

On Fri, Mar 9, 2018 at 9:49 PM, Mike Jones <

mike.jones.sysdev@xxxxxxxxx>

wrote:

Embracing SQL is all about "delegating".

IMO, this is similar in concept to OO programming, where you rely

more

on

others' objects, and have to let go of some of the details.

That's... an interesting opinion to have.

And you're certainly entitled to your opinions. But... the folks who
build the objects... do you not think of them as object-oriented
programmers?

Do you think of the object-builders as a different kind of

programmer

than the object-users?

How about the folks who write ILE modules, programs, or service
programs which are then used by RPG programmers? There's delegation
going on there too, but RPG is certainly not very object-oriented,

and

if you ask folks who use languages which are more widely recognized

as

object-oriented, they would call neither the service-program writers
nor the service-program consumers "object-oriented programmers".

And by the way, I don't think likening SQL to OOP is a great way to
entice Jon. He's been known to have his differences with OOP as

well.

;)

John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries)

(RPG400-L)

mailing list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)

(RPG400-L)

mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: http://amzn.to/2dEadiD

--
Regards,
Henrik Rützou

http://powerEXT.org <http://powerext.org/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
Regards,
Henrik Rützou

http://powerEXT.org <http://powerext.org/>