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

Paul,

See Alfredo's link for more info in SQL Server(Thanks Alfredo!)

My comments on ordering:

The issue on erodering is that ordering (e.g. the output of a Query) is no part of the relational model because the RM is expressed in set theory and sets do not have any ordering. Theoritically ordering is a function of the database client and not the database engine itsself, In practice ordering is available to any database implementation anyway since a database engine needs to solve (in)equality for all it's types, and hence is equipped to solve ordeing also.

On UDT's:

MS actually has several suggestions when to use UDT's. Don't use business entities !(like invoice or customer) Use small/simple entities like POINT(X,Y)

The disussion on what is a good UDT to define and what should not be attempted is pretty complex. Suffice to say MS is only giving you a
(low level) *implementation*, with which you can do almost anything
(shoot yourself in the foot e.g.;) The best understanding of what are
good (candidate) UDT's and why this is so is still "The Third Manifesto" by Date and Darwen.
I'm afraid this book serves as the best reference to actually be able to *properly use* the MS UDT feature at the moment.

Your address type is interesting, buit gives even more issues than you might think. E.g. in my country a zipcode and housenumber already uniquely defines an adress, so I suspect in my situation an address UDT would be a borderline case. In my country I would just store the housenumber and zipcode, and this would allow me to easily define
(in)equality and ordering as well.
Received on Fri May 27 2005 - 11:52:36 CEST