Re: Conceptual, Logical, and Physical views of data
Date: 8 Sep 2005 10:36:33 -0700
Message-ID: <1126200993.744970.17140_at_g47g2000cwa.googlegroups.com>
dawn wrote:
> Marshall Spight wrote:
> > > >
> > > > Everything you can do with pointers you can do with relational
> > > > operators. Pointers are neither necessary nor sufficient for
> > > > "navigation"; that is, finding the data you want.
> > >
> > > In that case, the API I use could have what I want, even if behind the
> > > scenes it uses relational operators, which behind the scenes use
> > > navigation, right?
> >
> > I don't see why you'd want to build an API on top of the relational
> > operators. You couldn't make them any more powerful;
>
> Why did we put relational operators on top of the prior interface?
We didn't.
> It didn't make it more powerful either. I'm interested in ease of use for
> developers.
If you want ease-of-use, then you want to work at the raise the level of abstraction. The best way to do that that I'm aware of is to use the RM. Certainly any function-based API will be a big step down.
> > you could
> > only make them *less* powerful. What would be the advantage?
>
> You mean like with 3GLs compared to assembler language?
Yes, exactly. 3GLs work at a higher level of abstraction. That's what you want 99.9% of the time. On a very few, very rare occasions, you want to drop down to a lower level.
> > Everyone in the java world wants to put a "framework" or
> > a customer API or some such between me and the database.
>
> It isn't like you are working with the database in a raw state
> otherwise, right? It is precisely the framework that is now on your
> average SQL-DBMS that I would like to see improved.
You misunderstood my use of the word "framework."
> > I've yet to see one that didn't cripple my interactions
> > with the db. I don't believe it's possible not to.
>
> Yes, precisely how I feel about that relational framework that was
> added to databases.
I acknowledge that you feel that way; however, I would prefer to focus on verifiable statements, and if possible formal claims.
> > > > provides a proper superset of the
> > > > functionality of the navigational operators.
> > >
> > > Just to be sure I understand this last statement, what do you mean by
> > > "addressing data by its content, rather than by its location"?
> >
> > You describe the data you want, and you get it.
> > select model from cars where color = blue;
>
> or how about "I'm looking at the data for Jane Doe and I'd like to
> follow the identifier for her spouse to see his birth date".
That looks fully content-based to me. Hard to say for sure since it's in English.
> > > Other than specifying a data source, what would be an
> > > example of addressing data by location?
> >
> > The "*" operator in C. A Url. Bulk mail addressed to "occupant." :-)
>
> I don't yet see how a URL is more of a pointer than a foreign key. It
> is an identifier. You can use it to "go to" another source of data
> just as you can use a foreign key to "go to" another source of data.
> It doesn't even point to a machine, even if it resolves to know what
> machine to go to. My foreign key used in a join statement knows that
> too.
We already discussed this to death. :-(
> > > Do you consider a base table name to be a location?
> >
> > No, because table names are semantic. Pointers are not semantic.
>
> If we use a URL as the value of a foreign key to a base table from
> which we can gen the html, then the URL would not be a pointer, right?
Right.
> So, it seems like it is the distributed nature of this vast database
> called "the web" that makes you think that the URL is a pointer.
Nope. Distributedness has nothing to do with it. It has to do with the nature of the *operator* you apply to get the results. With a Url, let's call that operator GET. Can you do anything with GET besides give it a Url and get back HTML? No; so it's a pointer; it exists only in the context of a dereference operator. Without GET, the Url is useless; it doesn't tell you anything.
Now, if you could supply GET with some attributes of the document
itself, that would be different. Let's say you could say:
GET title like "foo"
and get back all the documents on the web that had "foo" in the title.
Anyway, you're totally going down the wrong path with your focus on the web-as-database, anyway. The web is a document storage-and-retrieval system; as a database it's totally crippled. It has no semantic controls, schema, manipulation routines, nothing. Great for finding reading material, though.
Marshall Received on Thu Sep 08 2005 - 19:36:33 CEST