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

Ordering
I should have stated that all types that support =,<,> are part of an ordered domain (just equality is not enough, and indeeed types that only support equality do not have any ordering.) 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, and hence a pure relational language would not show ordering. Practically this does not mean a lot, since in SQL for example all sets are in fact all arrays.
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.

Addresses
I think going international with addresses is a disaster anyway, and this has nothing to do with modelling;) 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.

MS UDT
MS UDT's are probably limited, although I haven't bothered to investgate exactly how. I suspect MS UDT's need to be small and there needs to be a certain mapping to an integer domain(for serialization purposes) so types like POINT(X,Y), Complex numbers and Periods could work. IMO an option to implement UDT properties in seperate fields would have been more welcome than the ablity to customize serialization.

Alfredo, why is POINT(X,Y) in a full relational language(like tutorial D) not a good UDT? Received on Tue May 31 2005 - 17:25:50 CEST