Re: Logical equivalence of simple and complex types under the relational model?
Date: Thu, 2 Dec 2004 13:48:01 +0100
"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> Rene de Visser wrote:
> You are not forced into doing that, but it has been proven the sensible
> solution by some 50 years of experience with programming languages,
> logics and other formal language applications.
I have spent most of my life (so far) programming in imperative, functional
and OO langauges.
At the moment I am getting used to programming in a declarative relational language operating inside of an active database. It has some interesting 'unification' between types, functions and relations which seems to change the cost / benefits of doing things the way you normally would.
I agree with your statement above, but I think even the best programming languages that we have now are only about 10% of what an ideal language would be (I think that a clean mix of Glasgow Haskell (including extensions), peristant, relational and declarative languages is possible, just very difficult).
And that in such a programming language, where you are mostly operating at
the specification level will have different good programming practices than
the last 50 years of experience (which I think is very hetrogenous and
language type dependant).
> > [Aside: the address_id is not a pet. It can look after itself, or the
> > can look after it]
> So what exactly would an address_id be ? A reference to a particular
> address stoired in the central global_addresses ?
> >>There's no need to have "identity" for values. Values are
> >>self-identifying. If you have the number 3 you don't need an 3_ID for it
> >>to identify. So if you have the address ((zip 1234) (street "X no 4")
> >>(country "USA")) that's your value right there, just like the value 3.
> > Theres no need to have identity for complex type instances. But then I
> > claim that you need equivalence classes, and that these are effectively
> > same.
You are correct that there is no need to have identity for IMMUTABLE values. However from the way you had spoken about your address object, I had taken, that it was a mutable object.
> It depends on what you want to include in RM. If you want to include
> strictly relational algebra for theoretic explorations, than they are
> for all intents and purposes indistinguishable, because even the
> unnesting operators can be defined with standard operators against their
Yes I realised this later, than the decomposition can be done with the standard operators using the correct relations.
Many thanks for your replies. I have to do some reading up, and experimentation with these things. I will also be away for a month and so probably won't be able to reply sensibly to all your points in the next two months.
Rene. Received on Thu Dec 02 2004 - 13:48:01 CET