How is that better than if we put NULL into field and will check if it is not NULL? Actually if we allow NULL values for the column it is implemented as additional boolean flag for the column, so what you're proposing is just reimplementing of existing mechanism.

Because --as you can read in my other post in this thread-- "NULL" breaks the relational model and the meaning of "NULL" is ambiguous and such meaning cannot be derived from the database itself but must come from external sources. Meditate upon it and you will see I'm right ;-)

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

The database already provides such a field. To use your previous example,

Custom Field:

SELECT *
  FROM T
 WHERE HasAmount
   AND ( Amount = 10 OR NOT (Amount = 10) )
[download]

Provided Field:

SELECT *
  FROM T
 WHERE NOT IsNULL(Amount)
   AND ( Amount = 10 OR NOT (Amount = 10) )
[download]

Indeed, but it tells you nothing other than that there is no amount and not how we have to construe this missing amount. In other words, the database must find meaning outside of itself and that goes against the principles of relational model.

Everyone seems to misunderstand what I mean: Yes "NULL" can be quite practical, but it goes against the basic principles of the relational model, so I try to avoid it as much as possible. It is the same with database design: there is no law that says all your databases have to be in the Fifth Normal Form, but it is really handy if they are and you will avoid a number of problems (or at least it is easier to avoid these), but is it always worth the extra effort?

So use "NULL" if you like, but know what you are doing and why.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James