× 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.


  1.  Home
  2. RPG400-L
  3. March 2018

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

Mike,

to give you a theoretical scope of a NOSQL DB here is some simple
javascript code
that is completely out of the scope of SQL capabilities.

It also demonstrates that a NOSQL DB is quite different than a
row/column-based
RDBMS table because one inserted object in a collection dosn't necessary has
anything in common with the object next to it (has no common structure that
SQL
requires)


// myObject isn't JSON since it contains a function ( executable code)
myObject = {
messageFunction : function(message)
{ alert(message) }
}
myObject.messageFunction("Hello World")

// define a NOSQL DB, add a collection and insert myObject into the
collection
var myDB = new NOSQLdb("myDB.db")
var myFunctions = myDB.addCollection("myFunctions")
myFunctions.insert(myObject)


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

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/>





--
Regards,
Henrik Rützou

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






As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
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.