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

On 27 May 2005 02:52:36 -0700, "DM Unseen" <dm_unseen_at_hotmail.com> wrote:

>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

I disagree. Order makes no sense in relations, but in many cases we don't want to get a relation in response of a query, what we want are sorted arrays.

>, 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.

No, there are types in which order does not make sense.

>On UDT's:
>
>MS actually has several suggestions when to use UDT's.
>Don't use business entities !(like invoice or customer)

Good suggestion always.

>Use small/simple entities like POINT(X,Y)

This is not so good at the theoretical level but it is probably good with MS's implementation.

>The disussion on what is a good UDT to define and what should not be
>attempted is pretty complex.

This is true at a theoretical level, but the things are easier with rather poor implementations like M$'s one, in which only a few things work efficiently (or work at all).

> 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.;)

But a rather inflexible one.

> 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 agree.

>I'm afraid this book serves as the best reference to actually be able
>to *properly use* the MS UDT feature at the moment.

I disagree, we could find many proper uses that are impossible to implement efficiently with MS's UDTs.

>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.

Well, in my country a zipcode has nothing to do with the zipcodes of the neighbour countries, so an unlimited string could be a good option. I learned that from mistake.

> 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.

It would be easy anyway, but I doubt that Address is a good candidate for an UDT.

But I am afraid you could be in troubles with foreign customers.

Regards Received on Fri May 27 2005 - 18:12:28 CEST