为什么 null 被认为是不需要的默认值

Null 是该规则的一些例外，这会带来额外的困难，但对于 DBMS 开发人员而言比其用户更困难 - 如何在不更改可能值范围的情况下将空值与普通值分开，是否将此类条目包含在索引中（并将它们包含在索引的开头或结尾），如何使用 null 优化查询，在哪些情况下 null == null，在哪些情况下不。这给 DBMS 的最终用户提供了一点反馈——例如，很难在网上找到明确的答案，MySQL 是否在索引中包含 null，而我的朋友有一个案例（我注意到距离昨天还很远——在此期间可能会发生很多变化）当具有正常过滤的查询使用索引，而具有 null 过滤的查询不使用该索引时（同样，这可能是由查询本身的曲率引起的 - 我不'不敢说）；SELECT COUNT(*) WHERE field NOT LIKE '%'- 它是否应该计算空记录？）。因此，我认为由于某种存储限制而建议不要使用 null 更像是一个都市传说，而不是一个真正的问题（我间接地被谷歌的输出证实了，其中没有证据表明存在一个问题），只是在处理 null 时，您需要更加谨慎并更仔细地检验假设。

至于“用任何东西替换 null，只是不要使用 null”——我绝对不能同意这一点。在这种情况下，您为了存储库的便利而开始更改数据，这颠覆了 \u200b\u200btools 应该为正在解决的任务服务的想法，反之亦然。Null 是值的完全合法形式，表示不存在该值，并且绝不等同于任何中性值。我们可以想象下面的例子：有一个项目有用户，用户有手机号码，短信要发送到这个号码。数据库架构师可能会认为，为没有指定空字符串的用户处理空字符串比添加空检查更容易，但这实际上并不能解决问题，只会让问题变得更加困难：

• 发送 SMS 时，对 null 的检查将简单地替换为对字符串长度的检查。好处 - 零，应用程序的非直观性 - 增加
• 如果电话一开始就记录了 +7 和没有记录，并且决定修复它 - 你不能只将 +7 添加到所有记录的号码，因为在这种情况下空号码会变成 +7 ，SMS 将开始向无处发送 SMS，结果只有在那之后。

总结 - 数据是主要的，如果您缺少某些东西，例如鸭子，那么您需要记录鸭子的缺失，否则存在对缺失进行错误检查的风险。