Re: The Foundation of OO (XDb)

"Topmind" <topmind_at_technologist.com> wrote in message news:4e705869.0206180705.68bf5887_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
>
> news:<SctP8.3$eF1.678936_at_radon.golden.net>...
> > "Topmind" <topmind_at_technologist.com> wrote in message
> > news:4e705869.0206171151.6e02829b_at_posting.google.com...
> > > > What was wrong with the representation I gave?
> > > > I like it a lot better than yours
> > >
> > > 1. It was about food and not media libraries
> >
> > Huh? You are obviously talking about something else. It was about
> > representing Video as a data type in a dbms.
>
> I guess I don't know which schema example you are
> refering to. I only see food.
>
> >
> > > > Why not assume user-defined type support? I assume it.
> > >
> > > Do you mean "media format types"? I did not define
> > > nor limit who can change what. That is an orthogonal
> > > issue IMO.
> >
> > No, I mean user-defined type support such that Video is a data type.
>
> "Type" often implies operations, like "play", "rewind", etc.

These operations are application behaviours and not data behaviours. They navigate among the images within a Video to choose the next image to display. The DBMS delivers data (ie. the requested Video value or Image) and does not display.

> Mixing behavior into a database often delutes the power and
> advantages of databases IMO. For one, it reduces
> cross-language support. A database is not meant nor
> should be a media player.

Nobody (in this thread) ever claimed it should. (WebTV and Excel are not dbmses.)

> > > > Why should we force users to deal with filenames?
> > >
> > > This is the developer's perspective, not the users.
> > > I did not define nor limit user interfaces here.
> > > That is an orthogonal issue.
> >
> > What developer is involved when a user queries a database from Excel?
>
>
> What an Excel user has access to is not the issue here.
> I did not describe nor limit access controls.

I did. I asked the reader to imagine how a user might interact with such a relation in Excel or on WebTV.

> > I can see that. Video has multiple possible representations. Why force
> > anyone to choose? Why not support all the possible representations as
one
> > logical type?
>
> Because fat types don't belong in databases IMO.

Fat in what sense? In adequately supporting all possible representations of a type? I think that does belong in a dbms.

> A database
> and a media player are very different animals.

Yes, they are. Nobody (in this thread) ever tried to equate them.

> The database
> could *describe* the production item, but it should not be
> in charge of playing it.

You are shredding a straw man. Nobody ever claimed that the dbms should play videos.

> Fat types also tend to run into orthogonal divisions,
> granularity, and mutually-exclusiveness limitations
> in the long run IME.

I suggest you address the actual example given and not some example you imagine.

> For example, a player A may be able to play MPEG
> versions C, D, and E. But player B may only be
> able to play D and F. Thus, is the "type"
> divided by player or the version letters?
> Is each sub-version a different "type"?

No, they are simply representations of the same type. I thought that was very clear in my original example. Can you suggest ways I might have communicated it differently so that you would have understood?

> What about different implementations of
> MPEG players? Vendor M's version system
> may be completely different than vender N's
> version numbering system.

If the different Vendors players cannot, in general, play MPEG, then they are not MPEG players. If they can play MPEG, they should have no difficulty.

> Does that mean we are back to dividing by
> vendor drivers again?

MPEG is a standard representation. If your vendor's player does not play MPEG as claimed, take the player back to the store.

<remainder of fallacious argument snipped> Received on Tue Jun 18 2002 - 19:11:29 CEST