Re: Just one more anecdote

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > >
> > > I hate to get all Fabian-Pascally on you, but the thing about this
> > > is that the RM is based on set theory.
> > >
> > > I believe that you have identified quite a number of significant
> > > deficiencies in *SQL*, among them 3VL, lack of change management
> > > features, lack of support for ordered data, etc. I am fully
> > > subscribed to the idea that these problems can and should be fixed.
> > >
> > > At the same time, I *don't* believe that you've made even a chip
> > > in the giant granite edifice that is set theory, aka the RM.
> >
> > I have no intent whatsoever to discount set theory. I'm pretty sure
> > (not certain) that I don't want my entire API to a database to be in
> > terms of sets.
>
> I suspect that's simply because you/SQL/the world hasn't figured
> out how to tap into the full power of set theory yet.
>
I'm thinking of only using set operations when putting things into and taking things out of my purse. After all, that approach is based on set theory and set theory rules! ;-)
>
> > Are you sure that
> > you don't want a dbms product to do ordered lists,
>
> I'm sure I want my dbms product to be able to work well with that
> particular type of set that is an ordered list.

This is where we have a perspective problem. For purposes of this discussion, I will assume that my dbms product works well with data -- I want it to work well with me (with my developer hat on). There can be theories upon theories that are hidden from me, but those that affect the APIs I'll be using (that I think you are calling a language, perhaps?) are the ones I care about for preparation of both a logical data model and an implementation data specification.

In my API, if I do an insert into an ordered list, I don't want to manipulate any positioning attribute, or ever see one in any schema -- I simply want the insert function when applied to an ordered list, to perform an insert into that ordered list. This is so basic and yet I haven't seen a respectable API for this feature in any SQL-DBMS tools. I don't know if it exists in Dataphor, but I haven't seen it in any relational theory I've read.

>
> > to give you an api
> > for handing you a nodelist from a tree,
>
> I'm also sure I want my dbms product to be able to work well with that
> particular type of set that is a tree.

and, again, I want it to work well with me when I'm working with a logical tree.

> > to have a better built-in
> > understanding of a mapping, etc?
>
> And I'm sure I want my dbms product to be able to work well with that
> particular type of set that is a map, or a function.

Good job catching my change in terminology -- I seem to confuse people when I use the term "function" although it is my favorite data construct.

> I also want all of these things to be able to work together in a
> seamless, elegant, and yes, beautiful way. The only hope I know
> of for this happening is taking the set theory idea and turning
> it to eleven.
>
> If all I wanted to do was hack together a bunch of ad hoc
> functionality for all of the things you or I could enumerate,
> I could certainly do it with a big honking API library. The
> Java collections API does a pretty good job. But I want more.

I'm good with that. You are thinking of the design of a language and I'm thinking of using that language. I want it done well too. I will suggest that you don't have to be a one trick pony. You could provide an api for collections that are not sets or sets that are not relations or not only relations. If you want to refashion them into sets behind the scenes, have at it.

> > ... I don't think the RM is bad as a theory -- it is
> > using it as the exclusive means of working with databases and data
> > modeling where I'm not happy with it. Fair enough? --dawn
>
> I hear you, but I'm not there. Set theory is *foundational*,

If I need three cents in change, I have found it easier not to find all coins in my purse in order to project to just the pennies and then restrict to the ones I need. If I need three cents in change, a more helpful algorithm is to find one, then another, then a third and pay with these three. That does not negate the foundational value of set theory, it just makes for a better process. My purse can still have a set of coins, but it doesn't need to force me to use only set operations in my interactions with it.

> and
> it's important in language design to have a solid foundation.
> Again, I don't want a bunch of thrown-together ad hoc techinques
> that happens to be the union of everything I happen to have thought
> of when I designed the language, extended again and again as I
> thought of new things. I have plenty of approaches to do that today;
> all I have to do is write out tens of thousands of lines of procedural
> code in my application and I can have it all!

I think of it in terms of services (even before it was cool to do so) -- what does a software developer working with data (whether stored on disk, in memory, sent as a message, or input by a human) need to do and how can that language/api be as sweet as possible? If the software passes in these attributes, then the dbms software will have this and that output to here or there and return this to the calling software.

>
> I want something better. I want some *small* *simple* yet also
> *complete*
> core that will do all of these things using a set of operations that's
> so small that it looks ridiculous when you first look at it.

And is that your api, or is that your kernel?

> But
> still it provably does it all.

I appreciate that and think it to be better than an intellectual game as it can contribute to maintenance of your language/api. That isn't how we view relational theory today, however. It is often taught as THE api to databases.

> Not that this is an ambitious goal or anything. :-)

I appreciate aiming high cheers! --dawn

>
> Marshall
Received on Wed Aug 03 2005 - 19:35:48 CEST