At 02:06 PM 19/06/2003 +0200, Martijn wrote:

>I wouldn't say "same datatype" - but more "same meaning".
>
>That is, I will define seperate domains for, for example:
>
>ADDRESS varchar(80) and EMAIL varchar(80)
>
>although they are the same datatype.
>
>It's more of a conceptual thing. Better yet, the word "domain"
>explains it :-)

Yes, it's true there's a "conceptual" element in the thing. But the main
use of domains is to package a set of data attributes (type, size,
constraints) into a re-usable bundle. It doesn't matter if (as in the
simple example above) you define more than one domain with the same set of
attributes. If their contextual use is different, it might be
justified. You can add more constraints to a domain, as long as they won't
be violated by any data already using the domain.

So, taking the examples above, you could do this:

alter domain ADDRESS
add constraint CHECK (VALUE = UPPER(VALUE));

Now, this would be a pretty destructive constraint to impose on email
addresses, hence the value of keeping contexts apart sometimes.

A very good reason NOT to define a domain for every column in the database
is that Firebird already does it. Yep. Lurking in there in the metadata
are a gazillion domains with unique, invisible, ardeebeedollar names.

heLen