我今天从一家著名的SQL工具商业供应商那里读到了一份45条开发人员数据库性能提示的文档，其中有一条提示让我感到困惑：
如果可能，请避免在数据库中使用NULL值。如果没有，请使用适当的IS NULL和IS NOT NULL代码。
我喜欢NULL值，因为对我来说，如果一个值从未设置过，或者是0或string empty，那就有区别了。所以数据库有一个海豚。
那么，这个提示是无稽之谈，还是我应该采取措施来防止数据库表中出现NULL值呢？使用NULL值而不是填充的number或string值会对性能产生很大影响吗？
除了其他答案中提到的原因外，我们还可以从不同的角度看待NULL。
关于重复的行，Codd说
如果某件事是真的，说两次不会让它变得更真实。
类似地，你可以说
如果某件事是未知的，说它是未知的并不能让人知道
数据库是用来记录事实的。事实(真理)是公理，我们可以从中推断出其他事实
从这个角度来看，未知的事情不应该被记录下来——它们不是有用的事实
不管怎样，任何未记录的内容都是未知的。那么，为什么要麻烦录制它们呢
更不用说它们的存在使推论变得复杂了。
NULL问题并不简单。。。每个专业人士对此都有自己的看法。
关系论二值逻辑(2VL:TRUE和FALSE)拒绝NULL，Chris Date是NULL的最大敌人之一。但Ted Codd也接受了三值逻辑(真、假和未知)。
Oracle需要注意的几点：
-
单列B*树索引不包含NULL项。因此，如果代码为"WHERE XXX为NULL"，优化器就不能使用索引。
-
Oracle将NULL视为空字符串，因此：
WHERE SOME_FIELD = NULL与相同
WHERE SOME_FIELD = ''
此外，对于NULL，您必须在查询中注意，因为每次与NULL进行比较都会返回NULL。而且，有时，NULL是阴险的。想一想WHERE条件，如下所示：
WHERE SOME_FIELD NOT IN (SELECT C FROM SOME_TABLE)
如果子查询返回一个或多个NULL，则会得到空记录集！
这是我想谈论的最初几个案例。但我们可以谈论NULLs很多时间。。。
通常最好避免或尽量减少使用null。null会导致一些查询返回"不正确"的结果(即结果与数据库的预期含义不符)。不幸的是，SQL和SQL风格的数据库可能会使null难以避免，尽管并非不可能。这是一个非常实际的问题，即使是专家也经常难以发现由null引起的查询逻辑中的缺陷。
由于在现实世界中没有什么比null更好的了，使用它们意味着在数据库表示现实的方式上做出一些妥协。事实上，null没有单一的一致"含义"，也几乎没有就它们的用途达成一致。在实践中，null被用来表示各种不同的情况。如果您确实使用了它们，那么最好记录null对任何给定属性的确切含义。
以下是Chris Date:关于"零问题"的精彩讲座
http://www.youtube.com/watch?v=kU-MXf2TsPE
NULL有各种缺点，这可能会使使用它们比实际值更困难。例如：
- 在某些情况下，它们没有索引
- 它们使联接语法更加困难
- 它们需要特殊处理才能进行比较
对于字符串列，使用"N/A"或"N/K"作为一个特殊值可能是合适的，它有助于区分可能为NULL的不同类别，但对于数字或日期来说，这很难做到——特殊值通常很难使用，最好添加一个额外的列(例如，对于date_of_fornth，您可能有一个指定"reason_for_no_date_of_farnth"的列，这可以帮助应用程序变得更有用
对于许多数据值真正未知或不相关的情况，它们当然是完全合适的——date_of_death就是一个很好的例子，或者date_of_account_termination。
有时，即使是这些例子也可以通过将事件规范化到不同的表中而变得无关紧要，因此您有一个DATE_TYPES为"Open"、"Close"等的"ACCOUNT_DATES"表。
我认为在应用程序有适当的逻辑处理之前，在数据库中使用NULL值是可行的，但根据这篇文章，这里可能会讨论一些问题http://databases.aspfaq.com/general/why-should-i-avoid-nulls-in-my-database.html