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



Mike

How convenient to leave out the world’s most popular business programming
language (JAVA) and only base your “trend analysis” on Microsoft
proprietary product like C#, ADO and LINQ that always has a MSSQL database
in back and like IBM i/DB2 runs proprietary SQL.

I admit that SQL is pushing other techniques aside when it comes to DB
access, but that doesn’t tell anything about SQL used as a programming
language for other functionality.

Today I also work with javascript/node.js as the backend where SQL is seen
as “just another external service with a downloadable connector” and a
performance bottleneck that should be kept within the narrow ANSI/ISO
standard for portability and only used in dedicated REST/CRUD services were
it, by the way, not is used to either form the end-output or is used to
translate raw input from the HTTP buffer since there are no way to convert
a raw form/url encoded and escaped POST/GET input streams to anything that
matches anything in SQL. So, there are in any case a mapping from the DB
format to the external I/O interface of the REST service. Besides that,
there are always preprocessing before you come to the actual DB connection
e.g. security check, load of user specific rules and metadata for
conversion etc.

Node is for the moment mostly used as backend for front-end-applications
but that covers about 80% of the entire programming done today and with the
exception of isolated REST/CRUD you generally don’t find SQL used in any
part of the development simply because there is no database but only data
stores in the form of objects that holds data (result sets) and has built
in methods to access the data – all done in OOP.

So, you have to see at the full stack infrastructure of all the programming
techniques and elements used in the whole application production line.

Personally I consider SQL as a great language to connect to an internal RDB
but mapping to/from external client formats is most often in my experience
too complicated and therefore better done in traditional programming
languages simply because the internal database design seldom are the hand
that fit the glove of the external format – if it was so everybody had
built EDIfact and X.12 (that just is other hierarchical formats in another
syntax than XML/JSON) for years with SQL and I have never heard that done.

Another thing is that if you run node.js the SQL connectors doesn’t return
neither XML nor JSON as intermediate result set but a javascript object
that besides the result set also contain basic metadata for each column but
still misses the metadata that maps internal formats to external formats
basically the obvious - dates in numeric fields or date format of a data
field, Booleans that may be Y/N but in the interface 1/0 but also code
lists where 1,2,3 perhaps means USD, EUR, GBP etc.

The more advanced mapping is perhaps based on user rules, ´where User A
wants dates in ISO and clear text in French and User B wants dates in MDY
and clear text in English where the DB maybe has text in Danish and the
I18N text is translated by the REST service by either an I18N repository or
maybe by calling Google Translate Service. BTW how do you extend SQL with
Google Translate API? And finally there is of course the security issues.

So when it comes down to complex production ready code there is no such
thing as simple one statement solutions and should you be able to do all,
you would probably end up with a 1200 lines one statement SQL so nothing is
gained.


On Sun, Mar 11, 2018 at 4:42 AM, Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:

What you describe is outside the scope of the IBM i DB2 SQL, but is not
outside the scope of the SQL-like implementations that have been built to
run over NoSQL / HADOOP style databases.

NoSQL / HADOOP style databases are essentially key / value data-stores
where the "value" is unstructured data, like the "function" you inserted in
your example. In concept this is like inserting a BLOB into a database (or
a small object in your example). One way or another, those unstructured
objects will typically have one of more key names assigned to them, for
retrieval purposes. If you don't assign key names to those unstructured
objects, you essentially have a pile of random objects from which you can't
easily tell one from the other. That might be OK for some applications,
but most will have one or more key names, or attributes, assigned to the
unstructured object. The SQL implementations built to run over these
unstructured data stores feed off of the key names / attributes assigned to
the objects, but can also feed off the unstructured content of the stored
objects themselves.

SQL is an integral part of C#, via LINQ. LINQ queries very closely
resemble SQL syntax. Essentially, you can use LINQ (SQL like syntax) to
query and process run time collections of a wide variety of in-memory
objects. Those objects could be XML documents, JSON documents, simple
collections of integers, strings, or other data types, ADO.net data-sets
(in memory), collections of objects, and most other types of collections.
Essentially any collection that implements either the IEnumerable or
IEnumerable<T> interface can be queried using LINQ. So, I could use SQL to
fetch an ADO.net result set, and then use LINQ (SQL) to query that in
memory result set. Or, I could build a collection of functions like you've
described, and use LINQ queries to query the in-memory collection of
functions. Essentially, this means I can process in memory collections (of
just about anything), using SQL like syntax, and doing so will often reduce
the volume of code I'd have to create, versus if I were to iterate through
and process the collection manually. This is because the LINQ query is
generating a lot of code, that normally I'd have to manually create without
LINQ. When you combine LINQ with OOP reflection, you can use LINQ SQL at
run-time to query your classes, collections, objects, properties, and
methods, and based on what you find, determine what to do, at run time.
Very cool stuff, imo.

The trend I see is SQL => syntax <= is finding more and more uses in our
industry. I think there are four reasons for this:
1) It is widely known by developers, since it is commonly used, and
embedded inside many languages.
2) It is compact.
3) It is very read-able.
4) It is declarative. You define what you want done at a high level, and
code is generated for you to accomplish what you requested.

SQL is declarative syntax. It does a lot more today than just query
relational databases. In C#, it is an integral part of the language. I can
query my in memory stuff, filter it, process it. Using LINQ SQL syntax, I
declare what I want, and C# generates what I need to get that done.

For unstructured data stores like NoSQL and HADOOP, you declare what you
want via SQL syntax, and those SQL like implementations generate the code
needed to get that done.

The code generated by DB2 for i for relational data access, is completely
different than the code generated by C# for a LINQ SQL query, which is
completely different than the code generated by the SQL syntax
implementations built on top NoSQL / HADOOP. The code generated is vastly
different across those environments, but the SQL syntax is remarkably
similar.

Mike

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

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)



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.