Re: does a table always need a PK?

Christopher Browne <cbbrowne_at_acm.org> wrote in message news:<bifooh$8q46e$1_at_ID-125932.news.uni-berlin.de>...

<snippage>

> But that would likely cause anyone trying to use typically-used
> languages like COBOL, PL/1, BASIC, C, and C++ utter conniptions.
>
Very probably. But we've got to start somewhere - after all, if horrors like C++ can find a happy home in the world...

> The managers would cry 'But where can we get ML programmers? There's
> no market for that!'
>
Sadly so. Hope/ML/Haskell/Clean/FP-language-de-jour graduates seem to be a little thin on the ground. Mind you, a flourishing database environment with a Milner-esque type system might change matters ? Also, you don't necessarily need ML to get an ML-esque type system.  

> The programmers would cry 'Who is this Milner guy, and what did he do
> to my types?'
>
He took the pointers out and made it very easy to create (in Simon Peyton Jones' words) "sexy types" without spending weeks working out how to handle them. For real rapid prototyping, get with SML (or even better, Haskell) and bin those variables !  

> The ML programmers would look on in horror: "You want us to rewrite
> the _PAYROLL_ system?!?!"
>
Indeed - ML programmers asked to do *useful, productive* work ! It'd be a very odd sight :) Although Erlang programmers might have a head start there.  

> (And the guys at INRIA would shortly thereafter take over the
> world...)
>
Good God, I hope not !  

> I'm still a little suspicious of the way some of the type inheritance
> in Tutorial D works; some of it looks as though it's actually leading
> to a hierarchical structure, which would break some of the
> "relationality." Of course, it could be that I am misreading it; the
> "Tutorial" is not much of a tutorial...
>
Well, it kind of ties in to the denotational view of type structures in a way (the alpha and omega types kind of match up in a **very very** informal way to Top and Bottom), but I'm just not convinced that inheritance in the open is a terribly useful thing, for the amount of havoc it seems to create. If we start with a more interesting set of user extensible types and it then turns out we need inheritance (and all that comes with it) then fine, but I'd rather try something like the Milner system that's out there, available, pretty well understood and has been implemented in all sorts of places first.

Also, these are types, therefore orthogonal to relations. "Relationality" wouldn't break down even if you had a very hierarchical type system (you'd just be holding some very odd things in attributes). What isn't clear (and was the subject of an interesting post on DBDebunkings recently) is when to represent something with a type, and when with a relation. There doesn't seem to be a 100% applicable algorithm for that decision - and because of the lack of implementations, not much by way of rule of thumb either.

• Tony