Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?]
To   : comp.programming,comp.object
From : topmind
Date : Thu Sep 22 2005 11:54 pm


> Why would you need to demonstrate an ability no one disputes?
> How about you back up your original claim "relational==table"?

Somebody else is doing a wonderful job at it for me. A thousand thanks
to them. It takes many hunters to down a stubborn elephant.

>
> >>> The ODBC name is not the same thing as a "machine name". It
> >>> is essentially the name of a configuration, a "reference"
> >>> to a database (and usually a locally-stored configuration).
> >>
> >> Yes.  And **IN** that configuration is the machine name.
> >> If that changes, the configuration must change.
> >
> > Are you suggesting having the configuration point to
> > yet *another* configuration that is virtual?
>
> No, I'm talking about how ODBC connections work.  (Apparently this
> is yet another area of ignorance for you.)  Under the hood of every
> ODBC connection is a machine name.

Well of course. On a large scale it is a map (hash) between logical and
physical:

  logicalNameOne ------> PhysicalSourceAlpha
  logicalNameTwo ------> PhysicalSourceBeta
  logicalNameThree ------> PhysicalSourceAlpha

(Note that two logical names can refer to the same physical name, the
Alpha source in this case.)

What in it are you not happy about that arragement? By the way, it may
be possible for one logical name to reference another logical name, but
I've not tried that yet.

>
>
> >>>> Describe how you think an RDBMS would provide such a simple service.
> >>>
> >>>   UPDATE folders SET shared=true WHERE [folder criteria]
> >>
> >> You've missed the point.  This isn't about how to make a folder shared.
> >> It's about the ease of--once having a shared folder--dropping files,
> >> or copies of files, into that folder to share them.  Or the ease of
> >> removing them, or deleting the copies, to unshare them.
> >
> > Having a relational engine does NOT prevent having a one-click
> > icon for the masses any more than a tree-based file system
> > requires one to type MD or MAKEDIR or COPY. I did not propose that
> > every file operation be done with SQL or a query language.
>
> Um, that's exactly what you DID propose above.  How do you expect a one
> click icon to know what folder, what criteria?

As one of *many* techniques. There are several ways to browse and
search relational data. Query languages are one way, Query-by-Example
is another, which can be combined with "ID-set-processors" so that one
can perform set operations via mouse instead of queries. And it can be
combined with semi-natural language query techniques resembling a
Google search. Matching keywords could be hilited and close matches
could be next to a list of guesses. And a hierarchical-like drill-down
view can perhaps be created using arbitrarily ranked "levels" per
factor also for you tree fans that don't get it yet :-p

>
> And once again, you've completely missed the real point.  Which is, now
> that a shared folder exists, how do you move files and copies of files
> into and out of that "folder"?

This depends on whether the relational granularity is by folder or by
file. If by folder, it wouldn't be much different than hierarchical
systems. It would be like moving retail products 1,8, and 13 from store
A to store B; just like an inventory system. If at a file granularity,
"move" does not have much meaning. Relational transcends many of the
physical limitations of our physical world. You change attributes
rather than "move".

-T-

.