在SQL and Relational Theory(C.J.Date，2009)中，第4章主张避免重复行，并避免存储数据中的NULL个属性.虽然避免重复行没有问题，但我正在努力了解如何在不使用NULL的情况下对数据建模.以以下内容为例——这是工作中的一部分.
我们有一个artist表，其中有gender列.这是gender表的外键.然而，对于一些艺术家，我们不知道他们的性别-例如，我们收到了一份新音乐 list ，其中没有对艺术家的描述.在不使用NULL的情况下，如何表示该数据呢？我看到的唯一解决办法是在gender表中增加一个新的性别，"未知".
虽然我非常喜欢这本书，但当这一章以以下内容结束时，我真的很失望:
当然，如果是禁止空的，那麽遗漏的资料便要用其他方法来处理.不幸的是，这些其他方法太复杂了，不能在这里详细讨论.
这真是一个耻辱-因为这就是我等待阅读的解决方案！附录中有一个参考资料，里面有很多出版物可供阅读，但在我开始阅读这些之前，我希望能有更多一点实事求是的总结.
我得到了一些人的 comments ，他们不理解我为什么要避免‘null’，所以我会再次引用这本书.接受以下查询:
SELECT s.sno, p.pno
FROM s, p
WHERE s.city <> p.city
OR p.city <> 'Paris'
Now, take the example that s.city is London, and p.city is Paris. In this case, London <> Paris, so the query is true. Now take the case that p.city is not Paris, and is infact xyz. In this case, (London <> xyz) OR (xyz <> Paris) is also True. So, given any data - this query is true. However, if xyz is 'NULL' the scenario changes. In this case both of these expressions are neither True nor False, they are in fact, Unknown. And in this case because the result is unknown you will not get any rows returned.
从2值逻辑转移到3值逻辑很容易引入这样的错误.事实上，我刚刚在工作中介绍了一个，正是它激发了我的这个帖子.我想要type != 0位所在的所有行，然而，这实际上最终与type == 0 OR type IS NULL匹配-令人困惑的行为.
我对future 的数据建模是否使用NULL还不清楚，但我很好奇其他解决方案是什么.(我也一直认为，如果你不知道，你应该使用NULL).