At 07:36 PM 7/08/2003 +0000, you wrote:

>Is there any best pratice to use? If I create one dommain for each
>different type is a good solution? For example, one domain for
>char(2), one dommain for char(1), other to char(10). This is normal?

No. Generally, you would create a domain to comprise a number of
attributes, and then re-use that domain for all columns that need to have
those attributes.

There is no point in creating "one-use" domains that have no attributes
except data type. Firebird already does that.

Here are a couple of examples where domains are useful. All of my dynamic
tables have generated primary keys. Thus, in a Dialect 3 database, they
are always non-null BigInt. So I have this domain:

create domain d_identifier as
BigInt not null;

I generally key all of my "Type" lookup tables with a three-character
uppercase code, so I have this domain for them:

create domain d_typecode as
char(3) not null
check (value = upper(value));

And my Boolean type:

create domain d_Boolean as
char
check (value is null or value in ('T', 'F'));

I don't think it is a good idea at all to define domains purely on the
basis of type and size and then use them to define columns that are
controlled by different sets of business rules. One member of the domain
could change its requirements independently of other members' usages of
it. What happens then? Are you going to change the domain to fit that one
member, and break the domain for all of the other usages?

heLen