Re^6: DBI: passing undef as an argument

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]

Comment on Re^6: DBI: passing undef as an argument Select or Download Code

Replies are listed 'Best First'.
Re^7: DBI: passing undef as an argument by CountZero (Bishop) on Aug 12, 2009 at 19:43 UTC
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	[reply]
Re^8: DBI: passing undef as an argument by ikegami (Patriarch) on Aug 12, 2009 at 20:15 UTC
To which principle are you referring, and how is the definition of "HasAmount" less external than "IsNULL(Amount)"?	[reply]