Re: MV and SQL

David Cressey wrote:

> <michael_at_preece.net> wrote
> > x wrote:
> >
>
> > > - have the liberty to choose the programming language and reporting
> tools
> > > used to access the database
> >
> > Ummm.. OK. Here's where I show my ignorance. I thought the only way to
> > get data into or out of a SQL DBMS is/was through SQL. I thought that
> > was the only way to access the database. If I'm wrong about that then
> > please feel free to educate me a little - and have a go at me too while
> > you're at it if you like.
> >
>
> We all have areas of ignorance. So do I.
>
> Most of today's commercial SQL DBM systems have an object oriented interface
> as well, but that's kind of sidestepping the gist of your question.
>
> The real meat of your question is this: if you go in through SQL, and get
> the data in or out, what do you do with it outside of the database?
>
> SQL can be embedded in a report generator, such as SQR. (SQR has been
> renamed, but I don't remember it's current name). The report generator can
> manipulate the data in ways that are decidedly non-relational. My favorite
> engine for this kind of work was always Datatrieve.
>
> Here's why:
>
> The Datatrieve user ("programmer?") didn't have to learn SQL. Datatrieve
> had it's own syntax for select, project, and join operations, and it knew
> how to construct the necessary SQL on the fly, from the Datatrieve you had
> written (late binding?). It also knew how to perform these operations
> itself, albeit slowly, on data that was not housed in the same database, or
> even in a database at all.
>
> Thus, you could extract data from a hierarchical database, flatten it, and
> join it with a view from an SQL database all in one smooth Datatrieve
> statement. The Datatrieve statement looked far simpler than my description
> of it. The question of how much of the work was going to be done by
> Datatrieve itself and how much by the SQL server, was largely transparent to
> you, if you programmed in Datatrieve.
>
> But that example is kind of esoteric. Datatrieve never caught on really
> big, and most people today never heard of it. I expect that novel engines
> like Dataphor will end up reinventing that particular wheel.
>
> Another way to interface SQL with a more general purpose engine is to write
> SQL procedures that are callable from some traditional programming language,
> such as COBOL or PL/1. That's the way most of the database applications I
> worked with in the 1980s worked.
>
> The idea of using SQL, and only SQL, for all your data processing needs,
> sort of arose in the 1990s, and is overreaching. Here's my reaction:
>
> "I've got a hammer called SQL, and every problem is a nail."
> "Yeah, right."
> "I've got a hammer called Pick, and every problem is a nail."
> "Yeah, right."

Aren't you still talking about things sitting on top of SQL though? I mean - you're still talking to the database in SQL aren't you? Isn't that the only language it understands? Isn't everything beyond the SQL engine forbidden territory - the realm of the physical dragons? When I write VB code that's the way I interact with an SQL DBMS.

Mike. Received on Thu Jan 19 2006 - 15:08:31 CET