专家意见：避免NULL

Dr。Chris(C.J.)Date与关系数据模型的创建者/发现者(Codd博士)合作，他明确表示，"不，你不应该使用NULL。"阅读他的书《SQL标准指南》，了解更多讨论。

他和其他专家认为，对于各种理论和实践问题，NULL带来了太多的风险、困惑和问题，使其不值得。

解决方案：

在NOT NULL的每一列上添加一个约束
在有意义的地方，为每列添加一个默认值DEFAULT。对于文本类型列，默认值可以是空字符串(")。或者，默认的措辞可能是您任意选择并一致使用的某个措辞，如"空"或"不可用"，这取决于您的需求。在某些列中，您可能不希望使用默认值，这意味着如果用户/应用程序未提供值，您希望拒绝记录的插入或更新

规则例外

以上是一条很好的规则，我习惯性地遵循它。然而，每一条规则都有例外。在极少数情况下，我允许NULL例外。

示例异常：在Postgres中，当在数百万行的表中使用XML数据类型时。我需要反复搜索尚未记录值(缺少值)的行。我不能存储空字符串，因为Postgres强制要求只存储有效的XML，而空字符串不是有效的XML文档。所以我允许在XML列中使用NULL。

您可能认为我可以存储一个不包含任何数据的最小XML文档。但我不知道如何有效地对其进行索引，区分有记录数据的行和没有记录数据的列。我可以在NULL上创建索引。

关于这一点，大多数人都已经说过了，但我认为还有一件事需要考虑，如果你最终认为使用NULL或"作为"无值"(简单地说)是50/50。

在MySQL中，如果列的条件为负数，则NULL值不会被"捕获"。例如

where column != 'text'

将只返回"column"没有值"text"的行，但找不到"column"为NULL的行，如果您还想查找这些行，则必须使用：

where column != 'text' OR column IS NULL

我自己仍然喜欢使用NULL，并在保存之前将空字符串更改为nil，我认为最好知道数据库中的"空值"总是NULL。

另一方面，在某些情况下，您可能希望使用"无值"(NULL)和"空值"(")之间的差异。但我在某些申请中从未遇到过这种情况。

您应该始终使用NULL来表示列没有值，因为即使是空字符串也是值。

您需要决定"null"和空字符串的值在应用程序中的含义是否不同，或者它们两者的含义可能都只是"没有数据"。如果是后一种情况，那么这通常只是偏好的问题，但您必须是后果性的——尽量不要在给定字段中混合"null"值和空值。

一般来说，"null"给出了"无数据"的更好概念，但与空字符串相比，它在应用程序中使用起来有些麻烦。但是，使用空字符串而不是空字符串可能会被视为过早的优化，并且在未来的某个时候将不可能引入需要区分空字符串和空字符串的功能。

另一方面，DBMS不在字符串列中存储null，只存储空字符串。我会选择null，但有了完善的、有文档的契约(即"此字段从不包含null，空标题意味着没有标题"，对列强制执行NOT null约束)，您可以采取任何您喜欢的方法。

如果您关心性能，您需要阅读正在使用的DBMS文档，并自行进行一些测试。如果您预计空值非常频繁，您可以检查"稀疏列"是否有任何帮助-一些DBMS引入这些列是为了有效存储频繁出现的空值，但它们通常有一些缺点，比如检索非空值时会受到一般(通常不会太大)的性能损失，或者类似的情况。

当然，你必须考虑到客户的期望。但是，当您创建的数据库还没有被客户端访问时，就由您来决定并适当地记录它。

这并不严格适用于您的情况，但为了完整性，我会提到它：不强制使用NULL外键。

如果您有一个字段foreign_id，它是引用其他表的外键，则只有当foreign_id包含非NULL值时才会强制执行。

BTW，Oracle将空字符串存储为NULL。VARCHAR2保证会继续这样做，而VARCHAR可能(有一天)会被更改为符合SQL标准，并区分空字符串和NULL。据我所知，其他DBMS确实有这种区别

只有在数据未知或不适用时才使用Null值。。在所有其他情况下，在编写涉及NULL值的数据查询时，需要特别考虑使用"(空值)，这通常很困难。。

这取决于情况。你知道这个值是空的吗？示例：已知Person没有中间首字母。

还是你根本不知道？示例：您收到的表单中"中间首字母"字段为空。