Leyne, Sean wrote:

>> The firebird rdb$fields stores nullability value of the domain/column. Then
>> the rdb$relation_fields ALSO store the nullability value of the
>> domain/column (this looks like the actual override). So firebird still doesn't
>> support overriding the not null constraint on the domain???
>
> You make it sound like this is a problem. It is completely expected and appropriate.
>
> If you want to allow NULLs then define a new domain.

Completely agree. Imagine 2 people doing the development. One is data
architect, responsible for overall schema and domains. He decides that
some domain cannot be NULL and then architect the rest of the system
(perhaps even applications) around this fact. Now, imagine the second
developer using the system to code some little module. If we allow him
to override something that was preset at the very start, it could have
unforeseen consequences on the rest of the system.

In short, you cannot and should not go from "more constrained" to "less
constrained" when you are developing the system. If you need to do so,
it most likely shows that you are not doing things the right way.

OOP analogy to this would be creating a workaround function to get to
private member of the class so that you can alter it without class
knowing. It means you are either doing something that should not be
done, or that the system was not designed well from the start.

--
Milan Babuskov

==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================