Re: Microsoft and the two great blunders

Alfredo Novoa wrote:
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bsavog$bg13t$1@ID-152540.news.uni-berlin.de>...
>
>

>>Well, if you want to hold to the relational orthodoxy, you ought to call 
>>those relvar. But to make it clear we'll call them table, shall we ?

Table. Everybody and their grandmo know what a table is. Fore you, it is a relvar.But grandmo doesn't know what a relvar is.

>>Now let's further consider that the table EMPLOYEE stores all the tuples 
>>that have the type EMPLOYEE%ROWTYPE (using SQL terms, i.e. the type of 
>>the tuples).

Where monadic is the incorrect name for unary tuple ? In modern computer science the terms monads and monadic have a very specific usage. A relation is a set of tuples. Therefore a table may store all the values of a certain tuple type.

Probably you say there should be a distinction between a table with one column of type EMPLOYEE%ROWTYPE, and a table with n columns such as firstName, lastName, salary, etc -- all the components of EMPLOYEE%ROWTYPE.

This distinction is not even worth bothering to discuss, and a carefully designed relational DBMS would be able to skip over the differences.

>

>>I'm waiting for someone to make the case why would that be such a big deal ?

So then the great blunder, it's not such a big deal, or is it ?

>

>>Quite nice. But according to D&D types are sets of values. Well, then a 
>>relation is a set of value.

Not unless they've written one more edition of The Third Manifesto where they corrected their mistakes.

Here's a reference for you:
http://www.hughdarwen.freeola.com/TheThirdManifesto.web/D.GRM

As you may see, the user who declares a type has no mean to properly express a set of operators as integral part of the type definition.

Your definition "sets of values associated to sets of operators" is equally unsatisfactory. Does it mean that the definition of operators is integral part of type definition ?

Or to make it easier for you to express, here's an example from TTM:

TYPE PLANE_FIGURE ... ; TYPE ELLIPSE

	IS PLANE_FIGURE
	   POSSREP { A LENGTH, B LENGTH, CTR POINT };

The dots in PLANE_FIGURE definition belong to D&D. I suspect that the whole purpose why they are there is simply because they don't know what should be there in their place.

Now, I wonder what you or anyone would replace those dots with, within the framework established by D&D, so that it makes any sense whatsoever. But if the framework is so weak that it can't even deal with this much it should be either reformed or discarded altogether.

> On the other hand, a relation
> is an individual constant. But the "great blunder" is to confuse types
> with relation variables, not whith relations (values).

Nobody is confusing anything.

And this is no blunder. Most people *map* entity-types to tables. I.E. for every entity type found during analysis, they typically create a table in the relational schema to store values of that type.

> Another common
> mistake is to confuse values with variables all the time.
>

I think a lot of people got confused by the lack of formalism in TTM, the lack of a practical formal system (implementation ) to play with and understand all the practical implication of D&D proposals.

>

>>According to proper type theory, a type is much more, of course.

Not at all. See the above example. To tell you frankly, I doubt that anyone has an exact (meaning formal) idea what a type really is, according to D&D.

>

>>For lack of better things to do, people think that if they throw 
>>Microsoft and a couple of relational orthodoxy together, they've got a 
>>valid point.

Like ? Can you name one data management principle that the poewpoint, I suspect, is against ?

> The "Persistence Layer" approach leads to manage data in the
> applications using network structures, to move from declarative code
> to procedural code and to use DBMSes as mere file managers.
>

Move from what declarative code, to what procedural code ?

I frankly was able to use a "persistence layer" without dealing with any network structures whatsoever, but then there are also bad examples in the Java world.

Since the powerpoint is about a future Microsoft product, which you probably haven't studied yet, the criticisim is invalid.

> That's the big deal. It is a return to the stone age.
>

Return to stone age from where ? Where were you or Microsoft from that matter so that a powerpoint will return you to stone age. I suspect you were in some place better ?

> Microsoft kept away from this nonsense until now, that was reason
> because I posted the link.
>
>

Oh, common. Comp.database.theory has become a place where to unleash our rage against powerpoints ?

It would be a much better effort to prove that something else can be done instead.

> Regards
> Alfredo

Cheers and merry Christmas,
Costin Received on Thu Dec 25 2003 - 01:40:08 CET