Re: Navigation question

On Mar 6, 1:02 am, "dawn" <dawnwolth..._at_gmail.com> wrote:

[ snip ]

> Because it will be relevant, I'll include the original query I asked
> about
>
> Query TopFilms() As %SQLQuery(CONTAINID = 2)

Note that %SQLQuery.

>
> I'm not sure I should have included the history on this as it seems to
> have distracted you a bit too much.

This isn't history; well certainly not ancient history - 2003. And one of the closing quotes is :

"For example, both Caché SQL and the third-party KB_SQL product (http://www.kbsystems.com/), implement a full SQL environment, layered on MUMPS globals."

So basically, all of this chaos is lurking underneath some (optional - remember the %SQLQuery) window dressing. It isn't history, it's dreadfully current, it would seem.

> I simply did not want you to go off in an OO vs RM direction, while it
> appears you now are addressing the historical languages rather than
> the more recent advances, comparing SQL to MUMPS BASIC.
>

As per note above, it's not as if I went trawling the 1960s/1970s archives. And it isn't an OO vs. RM debate; it's a "hierarchical data storage system" that is "lean, mean and totally malleable" which offers "none of the controls, safety nets or value-added mechanisms that "proper" databases provide" vs. RM debate (all quotes culled from the paper I referenced previously).

[ snippage ]

>
> Don't forget, that is historical MUMPS, while Cache' has moved quite a
> bit further, it seems.
>

But only optionally, and then not as far as you might think.

>
> Cache's SQL is a flavor of SQL, but I agree it is just one of the
> interfaces to the data, not the only one as with many SQL-DBMS's,

The way you note that, it sounds like you think allowing the previously described mayhem is somehow an advantage.

> so
> it's OK with me if you call this, along with all of the other
> interfaces to the data "window dressing".

I may use the term "window dressing" somewhat pejoratively; M Gateway word it as "relational data definition can be transparently layered over the top of an existing set of MUMPS tables (globals)". Comes to much the same thing.

> That doesn't keep it from
> being one means for a developer to work with the database.
>

[ snip ]

> Yes, this is a well-worn topic.

Not worn enough.

> I do see that if a company cannot
> have the standards, controls and QA in place to have all developers
> use some standard libraries, then SQL-DBMS's are preferred as the
> standard libraries required are within the DBMS, rather than on top of
> it. There are trade-offs, however. Additionally, I have not yet
> found a company that is incapable of putting in place a central
> organization responsible for standard libraries and related procedures
> regarding the DBMS.
>
> I'm on your side on this one. I favor the SQL query over the
> iteration. My question was about the SQL(-ish) statement above.
>

But all this is still lurking under the window dressing; it's acquired some prettier syntax, but that's about it. The underlying "data model" (term used advisedly) is still the same.

[ snip ]

> I very much understand that the above SQL query, the one about which I
> asked this navigation question, does not have a join. It has,
> instead, a declaration of a "link" to navigate behind the scenes and
> then refers to that in the query. I do not yet see what is wrong with
> this navigation, although many suggestions have been offered that
> don't seem to hit the nail on the head. While it does not walk like a
> join, it has some of the same information of a join specified in the
> schema so that this SQL statement knows how to "walk the graph".

But as mentioned before this isn't SQL as SQL is; it's SQL dressing over MUMPS awfulness; since MUMPS is hierarchical/navigational/ iterative, it stands to reason this awfulness will bubble up into the SQL dressing.

> The
> example is one of logical navigation (the developer thinks in terms of
> navigating and specifies such to the DBMS). But is it an example of
> bad navigation? It does not include any procedural code nor
> iterations. Is this form of navigation bad, and, if so, why?
>

[ snip ]

> I'm with you on that, Tony. Please note that is not the case with the
> example given. The schema is declared in the language of a "class"
> which could turn off any anti-OO folks, but there is also an SQL
> interface to the catalog IIRC. Java, Cache' Object Script, SQL, PICK
> Query, PICK BASIC, MUMPS BASIC, ... are each different languages with
> which to work with the data. SQL and the RM are not the only way to
> work with the data. The developer can use the best hammer for the job
> or use their favorite hammer for all jobs (if organizational standards
> permit). So, you can get good code and bad and need proper quality
> controls, but I haven't seen any environment where that is not the
> case.
>

I am innately suspicious of anything that tries to say "there's more than one way to do it". Most computer based systems struggle to find one sensible way to attempt anything, never mind multiple ways. And, at the end of the day, all of this is laid over a storage engine with all the "qualities" mentioned above.

> A history lesson, which is worthwhile, but does not (from what I can
> tell) address the specific example--and example that does not use the
> old MUMPS BASIC code. Do you think what you have said about the
> historical code is relevant to the query above?

Yes, because the query presented sits on top of all the gnarliness described, and the "old" MUMPS code was still au courant enough to be promoted in 2003.

> Do you have any
> comments regarding the query example provided?

Yes. We should always be cautious of attempting to reason based on overly simple examples. (Didn't Djikstra caution along these lines ?)

• Tony