| Pete Dashwood 2007-03-13, 9:55 pm |
| Many people working in COBOL on both mainframe and Client/Server systems
deal with queries against relational data every day.
Over the years we have become adept with it and can usually get it to do
whatever we want. Most of us are satisfied we have this particular base
covered.
But, there are severe limitations in the "imperative programming" approach
as implemented by COBOL and other languages where we embed SQL.
If you are interested in where SQL is going, WHY the current approaches will
not be suitable for emerging architecture, and getting some straightforward
conceptual information from the horse's mouth, you may find this video
interview of interest..
http://wm.microsoft.com/ms/msdn/vis...Anders_0001.wmv
Functional programming represents the extension of the OO paradigm into the
next dimension. The interview with Anders Hejlstrom (who invented C#, among
other impressive credentials) is in plain English, and most programmers from
any background will be able to follow it.
(If you at least understand OO terminology it is helpful, but not essential.
There are a number of references to "IL"; this is "Intermediate Language"
and, for the purposes of this discussion, can be considered as you would
"machine code")
I have stopped using the "embedded SQL" approach with cursors and seqential
processing for some months now (mainly since I moved to C#, where the
alternatives are preferred and actually easier to implement...) and operate
instead on datasets, result sets, data and table adapters. I did this
originally because it meant less connect time and allowed connections to
databases to be shared and pooled in a much better way. (Also, queries
operate much better when they are directed at in-memory objects than when
they are directed at external disk files). After viewing the above interview
a couple of times I am now understanding why it is important to break away
from embedded SQL.
This is NOT the end of SQL!! (If you haven't already, start learning it...
:-)) It is the end of "embedded SQL" as we currently understand it...
Data that can be in any format, from any source, is what the future "SQL"
must deal with, and it must be capable of dealing with it concurrently
across multiple cores.
Can it be done? Hejlstrom thinks it can.
I'd be interested to hear what people here think.
Pete.
|