Re: Help! I can't support normalization

mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message news:<bdf69bdf.0211081037.358377d3_at_posting.google.com>...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<aqe3e2$ne8$1@sp15at20.hursley.ibm.com>...
> > "Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message
> > news:51d64140.0211070129.6fab7168_at_posting.google.com...
> > > OK then, what about complex numbers?
> > >
> > > Logically they are one "thing" so should you store them as "3+4i" in
> > > one column?
> > > Or as real part and imaginary part in two columns?
> > > Or even in two columns r, theta where z = r * e ^ theta?
> > > It's only for our convenience that we split them into two parts, the
> > > complex numbers with integer (real, imaginary) parts are countable so
> > > we could easily map them one to one with the integers.
> >
> > Don't confuse possible representations (read D&D) from the actual values
> > themselves.
>
> The question is if a representation spanning into 2 columns is
> legitimate.

I've been thinking about this some more and I think you can make an argument for keeping things like complex numbers in one column.

The reason being that a domain isn't just a set of values D but also a set of operators/functions on D^n. So for example your COMPLEX domain could have an operator that maps a complex value to the REAL domain (or some approximation of it) for |z| = sqrt(Re(z)^2 + Im(z)^2). Maybe other ones as well. Then all this functionality is encapsulated in your domain. If you stored the real and imaginary parts in two columns you'd have to store the operator essentially in the head of the DB user and reproduce it for any query where you needed it.

The other thing is storing points (or vectors) in a standard n-dimensional space e.g. (1,2,3) in three-dimensions. You might think that it should be in three separate columns. But supposing you wanted to define various operators like dot product or cross product it would be nice to only have to do it once (in your domain definition).

It does look strange having (1,2,3) in one column of your relation tuple. But really it's just notation, you could write "(1,2,3)" as "foobar" if you wanted.
You could think of it as a meaningless (to the RDBMS) string "(1,2,3)" that is sent to a "domain parser" whenever you need to perform some operation on it.

I can't off-hand think of any non-mathematical examples of this, maybe because non-mathematical domains tend to be fairly unstructured and don't have useful operators defined on them. But I'm sure there must be examples so I'll have a think.

Paul. Received on Fri Nov 15 2002 - 14:26:41 CET