Re: no names allowed, we serve types only

Tegiri Nenashi wrote:
> On Feb 13, 12:53 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:

>> Of course the conventional definition of a relation's header
>> is a set of ordered pairs of "attributes" of the form <A, T>
>> where A is the "name" of the attribute (which must be unique
>> within the header) and T is a type.

And users must be aware of types so that when a 'double' in one header matches the name but not the type of a double in another header, they will understand why join might produce an empty relation. (I may have misunderstood Keith D's idea, but I have the impression that it is just a substitute for '<rename>'. I think one could just ask what would happen if all 'doubles' had the same type - some kind of <rename> would still be needed.)

> The more I study relational model, the less I appreciate the concept
> of type (domain). This is consistent with dbms vendors failed to
> deliver genuine rdbms extensibility via user defined types: when did
> you last time program a new type? It looks like the only important
> operation on any domain is equality, and the other ones are just
> predicates in disguise.

In the old mainframe days, say up to about 1985, the OS'es and add-on products usually provided tons of 'exits'. (I suppose the modern term might be 'driver' points.) Usually they needed to be coded in some low-level language or assembler. Customers soon learned not to let any old programmer code them, but often they saved tremendous amounts of appl'n developer work-arounds (sometimes they amounted to just 'jobs for the boys'.)

Builtin types such as 'integer' and 'char' and even 'utf8' seem rather puerile to me, or at least beside the point as far as application relations are concerned, being related more to physical machines than to what Codd called 'domains'. It is a bloody shame that the mainstream so-called-relation products haven't done this, by now there might be a sizeable body of types that had been well shaken down. I imagine some of the current product developers are aware of D&D's work which could give them some fairly safe theory for guidelines to customers, indeed a whole sub-industry would be possible. I knew at least one product developer who put lots of secret exits in his code. When he was fired, he made a great living for several years, travelling the world and exploiting those secret exits (this wasn't a 'relational' product, rather one that could be called a fairly advanced 4GL, since programmers had to code their own joins, nevertheless it was good enough to beat the mainstream sql products in many purchase decisions for mainframe, unix and windows platforms).

Maybe I'm wrong, but I get the impression that many pretty smart people mistakenly think that 'user-defined' types means defineable by any old user and that product developers think this poses huge compiler/interpreter problems and big optimization problems. Although I've never seen them refer to this, I have the impression that D&D tacitly encourage that misperception, but I doubt if they really intend it, since they were both present during the 'old days'. I believe their motive is to establish principles that dictate implementation results, not ones that dictate implementation techniques. Received on Tue Feb 16 2010 - 03:05:59 CET