sql - 标准使用 'Z' 而不是 NULL 来表示丢失的数据？

Question

除了是否应该使用 NULL 的争论之外:我负责使用 NULL 来表示“丢失或从未输入”数据的现有数据库。它与空字符串不同，空字符串意味着“用户设置了此值，并且他们选择了‘空’。”

该项目的另一位承包商坚决主张“NULL 对我来说不存在；我从不使用 NULL，其他人也不应该使用”。然而，令我困惑的是，由于承包商的团队确实承认“丢失/从未输入”和“故意为空或用户指示为未知”之间的区别，因此他们在整个代码和存储过程中使用单个字符“Z”来表示“缺失/从未输入”，其含义与数据库其余部分中的 NULL 相同。

尽管我们的共同客户要求对此进行更改，并且我也支持此请求，但团队将此视为比我先进得多的 DBA 中的“标准实践”；仅基于我无知的请求，他们就不愿意更改为使用 NULL。那么，谁能帮我克服我的无知呢？是否有任何标准，或一小群人，甚至 SQL 专家中的一个响亮的声音提倡使用“Z”代替 NULL？

更新

我有承包商的回复需要补充。当客户要求删除特殊值以允许没有数据的列中出现 NULL 时，他是这样说的:

Basically, I designed the database to avoid NULLs whenever possible. Here is the rationale:

• A NULL in a string [VARCHAR] field is never necessary because an empty (zero-length) string furnishes exactly the same information.

• A NULL in an integer field (e.g., an ID value) can be handled by using a value that would never occur in the data (e.g, -1 for an integer IDENTITY field).

• A NULL in a date field can easily cause complications in date calculations. For example, in logic that computes date differences, such as the difference in days between a [RecoveryDate] and an [OnsetDate], the logic will blow up if one or both dates are NULL -- unless an explicit allowance is made for both dates being NULL. That's extra work and extra handling. If "default" or "placeholder" dates are used for [RecoveryDate] and [OnsetDate] (e.g., "1/1/1900") , mathematical calculations might show "unusual" values -- but date logic will not blow up.

NULL handling has traditionally been an area where developers make mistakes in stored procedures.

In my 15 years as a DBA, I've found it best to avoid NULLs wherever possible.

这似乎证实了对这个问题的大多数负面 react 。不是应用公认的 6NF 方法来设计 NULL，而是使用特殊值来“尽可能避免 NULL”。我以开放的心态发布了这个问题，我很高兴我了解了更多关于“NULL 有用/NULL 是邪恶”辩论的信息，但我现在很乐意将“特殊值”方法标记为完全无稽之谈。

an empty (zero-length) string furnishes exactly the same information.

不，不是；在我们正在修改的现有数据库中，NULL表示“从未输入”，空字符串表示“输入为空”。

NULL handling has traditionally been an area where developers make mistakes in stored procedures.

是的，但是这些错误已经被数千名开发人员犯过数千次，并且避免这些错误的教训和注意事项是已知的并记录在案。正如这里提到的:无论您接受还是拒绝 NULL，缺失值的表示都是一个已解决的问题。没有必要仅仅因为开发人员不断犯易于克服(且易于识别)的错误就发明新的解决方案。

<小时/>

作为脚注:我担任 DBE 和开发人员已超过 20 年(这当然足以让我了解数据库工程师和数据库管理员之间的区别)。在我的整个职业生涯中，我一直站在“NULL 很有用”阵营，尽管我知道一些非常聪明的人不同意。我对“特殊值”方法非常怀疑，但对“如何以正确的方式避免 NULL”的学术不够精通，无法做出坚定的立场。我总是喜欢学习新事物——20 年后我仍然有很多东西要学。感谢所有为使本次讨论成为有益的讨论而做出贡献的人。

Answer 1

解雇你的承包商。

好吧，说真的，这不是标准做法。这可以简单地看出，因为我曾经使用过的所有 RDBMS 都实现了 NULL、NULL 的逻辑、在外键中考虑 NULL、在 COUNT 中对 NULL 有不同的行为等等。

我实际上认为使用“Z”或任何其他占位符更糟糕。您仍然需要代码来检查“Z”。但您还需要证明“Z”并不意味着“Z”，它意味着其他东西。并且您必须确保阅读此类文档。那么如果“Z”成为有效数据会发生什么？ (例如缩写字段？)

在基本层面上，即使不争论 NULL 与“Z”的有效性，我也会坚持要求承包商遵守贵公司而不是他公司内部存在的标准做法。在具有替代标准实践的环境中建立他的标准实践将导致困惑、维护开销、误解，并最终增加成本和错误。

<小时/>

编辑

在我看来，在某些情况下使用 NULL 的替代方案是有效的。但只有这样做可以减少代码，而不是创建需要考虑的特殊情况。

例如，我已将其用于日期绑定(bind)数据。如果数据在开始日期和结束日期之间有效，则可以通过不使用 NULL 值来简化代码。相反，NULL 开始日期可以替换为“01 Jan 1900”，NULL 结束日期可以替换为“31 Dec 2079”。

这仍然会改变预期的行为，因此应谨慎使用:

• WHERE end-date IS NULL 不再提供仍然有效的数据
• 你刚刚创造了自己的千年虫
• 等等

这相当于改革抽象，使所有属性始终具有有效值。它与将特定含义隐式编码为任意选择的值明显不同。

不过，解雇承包商。