Re: (domain support) Re: theory and practice: ying and yang

On 31 May 2005 08:25:50 -0700, "DM Unseen" <dm_unseen_at_hotmail.com> wrote:

>It is interesting to see that in practical terms a relational engine is
>already capapable of solving ordering, but is not able to express in it
>sets,

Well, it is very easy :)

relation {
  tuple { Order 1, Address "xxx" }
  tuple { Order 2, Address "yyy" }
}

>Practically this does not mean a lot, since in SQL for example all sets
>are in fact all arrays.

No, in SQL the queries with the "order by" clause return arrays. The other queries return sets or multisets.

>Alfredo's comment on making arrays also explicitly available in a
>relational language(in contrast to just a client comupter language)
>looks interesting, but ordering will still be a *language* issue and
>not a RM issue.

Indeed.

>Addresses
>I think going international with addresses is a disaster anyway, and
>this has nothing to do with modelling;)

I disagree. To support international addresses is often a must, and then we have to create database designs that support them.

>Only some address/zipcode
>schemes are useful as an UDT(and surprisingly the Dutch postal service
>employs one;), but most will not work as an UDT, so employing a long
>string is as good as anything.

And that is modelling :)

>Alfredo, why is POINT(X,Y) in a full relational language(like tutorial
>D) not a good UDT?

IMO POINT(X,Y) is an excellent candidate for an UDT.

What I said is that entity types like: Customer, Invoice, etc, are bad candidates.

Regards Received on Tue May 31 2005 - 18:03:12 CEST