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)
midrange.com
