除了是否应该使用NULL之外的参数:我负责使用NULL表示"丢失或从未输入"数据的现有数据库.它与空字符串不同,这意味着"用户设置此值,并且他们选择'空'."
该项目的另一个承包商坚定地认为"对我来说不存在NULL;我从不使用NULL,其他任何人都不应该,"论证的一方.然而,令我感到困惑的是,由于承包商的团队确认"丢失/从未输入"和"故意空白或用户指示为未知"之间的区别,他们在整个代码和存储过程中使用单个字符"Z".在整个数据库的其余部分表示"缺少/从未输入",其含义与NULL相同.
虽然我们的共享客户要求更改此项,并且我已经支持此请求,但团队认为这是比我更先进的DBA中的"标准做法"; 他们不愿意根据我的无知请求单独更改为使用NULL.那么,任何人都可以帮助我克服自己的无知吗？在SQL专家中是否有任何标准或小组的个人,甚至是一个大声的声音,主张使用'Z'代替NULL？
我得到了承包商的回复.以下是当客户要求删除特殊值以在没有数据的列中允许NULL时他说的话:
基本上,我设计数据库以尽可能避免NULL.这是基本原理:
• 字符串[VARCHAR]字段中的NULL永远不是必需的,因为空(零长度)字符串提供完全相同的信息.
• 整数字段中的NULL(例如,ID值)可以通过使用数据中永远不会出现的值来处理(例如,对于整数IDENTITY字段,为-1).
• 日期字段中的NULL很容易导致日期计算的复杂化.例如,在计算日期差异的逻辑中,例如[RecoveryDate]和[OnsetDate]之间的天数差异,如果一个或两个日期为NULL,逻辑将会爆炸 - 除非明确考虑两个日期为NULL.这是额外的工作和额外的处理.如果[RecoveryDate]和[OnsetDate]使用"default"或"placeholder"日期(例如,"1/1/1900"),则数学计算可能会显示"异常"值 - 但日期逻辑不会爆炸.
传统上,NULL处理是开发人员在存储过程中出错的一个领域.
在我担任DBA的15年中,我发现尽可能避免使用NULL.
这似乎证实了对这个问题的主要负面反应.不使用接受的6NF方法来设计NULL,而是使用特殊值来"尽可能避免使用NULL".我以开放的心态发布了这个问题,我很高兴我学到了更多关于"NULLs is useful/NULLs is evil"的讨论,但我现在很乐意将"特殊值"方法标记为完全无稽之谈.
一个空的(零长度)字符串提供完全相同的信息.
不,它没有; 在我们正在修改的现有数据库中,NULL表示"从未输入",空字符串表示"输入为空".
传统上,NULL处理是开发人员在存储过程中出错的一个领域.
是的,但成千上万的开发人员已经成功地做了数千次错误,并且已知并记录了避免这些错误的经验和警告.正如这里提到的:无论你是接受还是拒绝NULL,缺失值的表示都是一个解决的问题.没有必要发明新的解决方案只是因为开发人员继续做出易于克服(且容易识别)的错误.
作为一个脚注:我已经成为一名DBE和开发人员超过20年(这当然足以让我知道数据库工程师和数据库管理员之间的差异).在我的整个职业生涯中,我一直都在"NULLs是有用的"阵营,虽然我知道几个非常聪明的人不同意.我对"特殊价值观"的方法持怀疑态度,但对于"如何避免正确的方式"的学术问题却不够精通,无法做出坚定的立场.我一直喜欢学习新东西 - 20年后我还有很多需要学习的东西.感谢所有为此做出有益讨论的人.