Re: Navigation question

On Mar 5, 5:36 pm, "Tony D" <tonyisyour..._at_netscape.net> wrote:
> On Mar 5, 5:25 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
>
>
> > Hi Tony -- I'm hoping you are still in a good mood.
>
> Well I was until Google dumped the first attempt at a response to this
> down the memory hole. Ho hum.

The new interface seems to lose your data when it barks more often than the old one, including my response to you here, which I fortunately saved before attempting to send, eventually crashing FF and rebooting.

> [ snips-a-daisy ]

<more snipping>
Because it will be relevant, I'll include the original query I asked about

Query TopFilms() As %SQLQuery(CONTAINID = 2)

	{
		SELECT Description,%ID,Length,Rating,Title,"Category->CategoryName"
		FROM Film
		WHERE (PlayingNow = 1)
		ORDER BY TicketsSold DESC
	}

found at http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TWEB_TopFilmsQuery8 with the setup some pages back from that in case it is not clear that you get Category Name by "navigating" to it.

> > This MUMPS-like example is slightly different from the more PICK-like
> > example I gave earlier. In spite of the data being model as both
> > objects (with the classes) and relations (with the SQL-ish query), the
> > logical data model is specified without methods, so no one needs to
> > launch into OO vs Relations on this one, I hope. This data model
> > (MUMPS) pre-dates relational and OO.
>
> Settle in, we could be here a while.
>
> Well, I took it upon myself to look MUMPS up on Wikipedia, which led
> me to this lovely document here :
>
> Globals - A Primer for Relational Programmershttp://www.mgateway.com/extreme1.doc
>
> This is a document to demonstrate to mere relational programmers the
> joys of working with MUMPS, in all its navigational, hierarchical and
> yes, iterative glory.
>
> I won't bore you with all the details, but I will share a couple of
> fantastic quotes and one example with you.
<snipping some of the fantastic quotes>

I'm not sure I should have included the history on this as it seems to have distracted you a bit too much.
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.

> The example query I'm going to list here, stated by the authors in
> SQL, is embarrassingly trivial. It changes the customer number in the
> customers table. There are referential integrities declared so that
> this change will ripple down to the orders table. The query, as given
> by the authors of the paper, is
>
> UPDATE CUSTOMER A
> SET custNo = :newCustNo
> WHERE A.custNo = :oldCustNo
>
> Like I say, nothing fancy. Let's look at the MUMPS code.
>
> As Paul Daniels would say, "You're going to like this. Not a lot, but
> you'll like it."
>
> updateCustomer(oldCustNo,newCustNo,newData) ;
> new result,orderData,orderNo
> if (oldCustNo="")!(newCustNo="") Quit 0
> set orderNo=""
> for set orderNo=$order(^ORDERX1(oldCustNo,orderNo)) Quit:orderNo=""
> do
> . set result=$$getOrder(orderNo,.orderData)
> . set orderData("custNo")=newCustNo
> . set ok=$$setOrder(orderNo,.orderData)
> set ok=$$setCustomer(newCustNo,.newData)
> if newCustNo'=oldCustNo set ok=$$deleteCustomer(oldCustNo)
> Quit 1
>
> Oooh, look at that lovely for-loop iterating over the orders ! But
> wait a minute, what's that ORDERX1 thing ? Well, it turns out that
> that is another global that the MUMPS programmer has set up in this
> case to provide pointers (natch !) from customers to orders. So, we've
> started with a customer number, iterated over a bunch of pointers to
> some other data and done work with that data. Sound navigational yet ?
>
> Sorry, did you think you were finished ? Nahhhh ! This is MUMPS, where
> the Real Programmers hang out.

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

<snip>
> Well, really. I cannot honestly believe that in this day and age
> someone would willingly inflict this sort of nonsense upon themselves.
> And, I have stuck to exactly what is in the text, and these people are
> *advocates* of this stuff.
>
> "But Tony," you might say, "what has this got to do with navigation ?"
>
> "Well," I would say, "observe the pointer maintenance, the traversal
> of globals, the mentions in the paper of the concept of 'nodes', and I
> think that adds up to a pretty grim picture of a navigational,
> iterative, roll your own database set up."
>
> "But," you may retort, "surely you could write this kind of bumph in
> SQL ? What about selecting data from one table into a variable, then
> using that variable to qualify queries on other tables ?"
>
> "Well," I would answer, "that might *look* like this kind of thing.
> The tactic is the same. But there are (barring 'connect by' et al) no
> pointers, and no traversal going on. The queries are logically
> separate. They are written by programmers who are at best naive, and
> at worst incompetent, and there is almost always a better way. In a
> system like MUMPS, you have no option."
>
> "But surely Caché allows SQL ?" you may be moved to say.
>
> "Indeed," I would answer, "but only as some window dressing to this
> bumph. This stuff is still creeping out from under the covers, waiting
> to bite you.

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, so it's OK with me if you call this, along with all of the other interfaces to the data "window dressing". That doesn't keep it from being one means for a developer to work with the database.

> And would you care to consider, what would happen if
> another programmer were to access your globals directly, without going
> through your lovely procedures ?"

Yes, this is a well-worn topic. 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.

>
> > Is there something problematic or bad about this form of navigation.
>
> Well, just look at it. The really try telling me there's nothing wrong
> or bad about this. Go on, have a shot at convincing me. Go for it, I'd
> love to see someone try to stick up for this.

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.

> > If not, then I might finally have my answer.
> > If so, is it bad in the same way that it is bad to specify a JOIN in
> > an SQL statement
>
> Well, we're nearly 200 posts into this thread, and hopefully there's a
> little inkling that although this might look like a join, it don't
> walk like a join or quack like a join, so it ain't a join.

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". 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?

> > in a
> > problem because that means the developer has to know where the data
> > are located, or is there something additonally problematic with
> > navigating like this? Thanks. --dawn
>
> Consider the number of concepts, ideas, mechanisms and the amount of
> code that has been written to do the job of three lines of SQL and a
> couple of declarative constraints.

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.

> We've got nodes, pointers,
> subscripts, subscript levels, collating sequences, globals,
> navigation, iteration, procedures and a bag full of user written code.
> And what has it got us ?

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? Do you have any comments regarding the query example provided? Thanks. --dawn

>
> *whoosh* there goes an ancient English razor
> (it does fit the tune of "High Hopes", just)
>
> - Tony
Received on Tue Mar 06 2007 - 02:02:20 CET