Re: The Foundation of OO (XDb)

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

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.

"Dammit Jim, I am a doctor, not an MP3 player."

"Stop fussing, McCoy and keep singing. The aliens have almost melted."  

>
> > > 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. An orthogonal issue IMO.

(Note that ACL's are the best general-purpose and scalable security solution that I know of. They are much more powerful and flexible than OO-style "encapsulation" But, we are not discussing ACL's nor security here.)

>
> 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. A database and a media player are very different animals. The database could *describe* the production item, but it should not be in charge of playing it. Players are very client-centric technology.

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

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

What about different implementations of
MPEG players? Vendor M's version system
may be completely different than vender N's version numbering system.
Does that mean we are back to dividing by vendor drivers again? IOW, I see orthogonal issues here between media players and
media formats.

Dividing by the content
format won't be enough to tell us which
player it will work with. Sometimes you
don't know until you actually try to play it. A bug in player X may prevent you from watching movie 7, but player Y may play it just fine, despite being rated for the same format. Maybe driver R works fine on AMD, but not on Pentiums.

We now have 3 potentially independent axis here:

1. Media format
2. Driver (software)
3. Hardware (CPU, etc.)

It will not be easy to turn these into
usable "types".

Whenever one studies closely possible
classification and modeling approaches to such things, you usually end up something that does not slice up nicely into
"types". Fat types would be wonderful if they worked in practice, but reality
is messier and meaner than that.

If you want practice, divide people
into "types" for a year or so.

I am just the messenger. You can only shoot me on every 3rd harvest moon of the year if interest rates increase less that .2
percent for more than 3 consecutive weeks.

-T- Received on Tue Jun 18 2002 - 17:05:28 CEST