您可能已经知道，在不可为null列上设置默认值有助于摆脱那些讨厌的“Field 'xyz' doesn't have a default value”错误。希望您也意识到，防止发生错误信息本身并不是提供默认值的有效理由。提供默认列值的原因很多，有些很好，有些则不怎么好。我们在第1部分探讨了MySQL严格SQL模式的影响，以及如何使用Navicat for MySQL 15对其进行查看和设置。在今天的后续文章中，我们将探讨何时使用默认值以及如何选用恰當的默认值。
为什么不只允许Null值？
可以为null列不会像不可为null列那样面临有同样的问题，那么为什么不在所有非键列中都允许null值呢？在许多情况下，将不可为null约束应用于列的目的是迫使填充该列的应用程序或系统提供值。有时，不可为null列可能包含审核信息，例如用户ID或时间戳。无论哪种情况，您都在寻找有效的数据，而不仅仅是填充的数据。
这是一个重要的考虑因素，因为它带出了生成有用的默认值以及前端验证的重要性。我仍然记得我的第一个Web应用程序。它是用于收集了用户详细信息，例如姓名，电子邮件和电话号码。所有这些字段都是必需的，因此聪明的用户找到了各种规避输入真实信息的方法，例如输入电话号码111-111-1111和“Elmer J. Fudd”之类的名称。
产生时间戳
现在，我们已经讨论了为什么值得尽您所能尝试设置自动填充字段，下面让我们看一下生成值的常见示例：审计时间戳。
Sakila示例数据库中的一些表具有last_update列。这些列应用timestamp数据类型；其值设置为MySQL CURRENT_TIMESTAMP函数的输出。在Navicat Premium中（如下图所示），您可以通过下拉列表设置默认值：
“默认”值设置记录创建时的时间戳，而选中“根据当前时间戳更新”框则指示MySQL在每次更新操作时更新时间戳。
前哨值
在RDBMS中，前哨值（Sentinel Value）是具有特殊含义的值。 例如，年龄列中的值999表示它是未知的。 我还看到了使用“1900-01-01”作为未知日期的应用程序。 前哨值在您要分配“未知”值的情况下很有用，而null值表示“无值”。 并非每个人都喜欢哨兵值，因为使用数据库的人员和应用程序必须知道所有哨兵值才能正确处理它们。
总结
尽管默认值以及引申开来的前哨值在组织良好的数据库设计和开发中具有他们的地位和价值，但在分配值之前，应考虑每个值的用途。 仅仅依靠默认值来避免使用null可能不是一个足够好的理由。
