Re: Conceptual, Logical, and Physical views of data

From: dawn <dawnwolthuis_at_gmail.com>
Date: 8 Sep 2005 09:41:30 -0700
Message-ID: <1126197690.675030.191830@o13g2000cwo.googlegroups.com>

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > > dawn wrote:
> > > >
> > > > I do want navigational
> > > > operators, however and that seems to go against relational theory. I
> > > > want to "click on" a foreign key value and navigate to the referenced
> > > > entity.
> > >
> > > 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? It didn't make it more powerful either. I'm interested in ease of use for developers.

> you could
> only make them *less* powerful. What would be the advantage?

You mean like with 3GLs compared to assembler language?

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

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

>


> > > Addressing the data by its content, rather than by

> > > its location,

> >

> > I'm all for addressing data by its content.  I still don't know whether

> > it is proper to call a foreign key a pointer or not, but it is surely
> > data.

>

> My position is that FKs are not pointers.

>
>


> > > 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". Of course this can be said with relational operators, but I want to use the "from where I'm sitting now, here is where I want to go" approach some of the time.

>

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

>

> > 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? 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. Am I missing something? --dawn

>
> Marshall
Received on Thu Sep 08 2005 - 11:41:30 CDT