关于如何处理空值的最佳实践是什么
在您的数据库和/或代码中。
您是否避免使用空值，或者是否明确编程以在逻辑中处理空值？
如何处理空值的最佳实践是什么？
In you database and/or code.
Do you avoid nulls or do you explicitly program to handle them in your logic?
What is best practice on how to handle nulls?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
空值的基本问题之一是其解释没有单一的普遍接受的含义，因此使用空值的结果经常不一致并且与预期含义不同。
通常，必须对最终用户隐藏或某种程度地抽象空值。因此，如果开发人员决定将空值放入数据库中，他通常还必须确定稍后如何再次删除它。
由于这些原因，完全避免使用 null 或尽量减少它们的使用是有意义的。
如果您确实允许空值，那么您应该仔细定义这些空值的含义和正确处理，并确保您的代码正确处理它们。如果您不使用空值，那么您通常不需要这样做 - 尽管您可能希望设计代码，以便即使数据库中不存在空值也不会生成空值。
One of the basic problems with nulls is that there is no single generally accepted meaning for their interpretation and therefore the results of using nulls are frequently inconsistent and different to the intended meaning.
Typically nulls have to be hidden or somewhat abstracted from end users. Therefore if the developer decides to put a null into a database he usually also has to determine how to remove it again later on.
For these reasons it can make sense either to avoid using nulls altogether or to minimise their use.
If you do permit nulls then you should carefully define the meaning and correct treatment of those nulls and make sure your code handles them correctly. If you don't use nulls then you don't usually need to do that - although you may want to design your code such that nulls don't get generated even where none exist in the database.
空值是“任何现有 SQL 引擎都不可避免的”，也是“数据管理的瘟疫和霍乱合而为一”。
使用 SQL 时，关键是要记住 SQL 表实际上处于“物理设计”级别，您只想保留同一对象的不同属性 p1、p2、p3 的单个记录，并由某个标识符标识I，作为单行（I，p1，p2，p3）。即使其中一些属性碰巧是“未知的”。 （我没有提到“N/A”。这种特殊含义暴露了设计缺陷。）
但是 SQL 级别与您的应用程序（/用户）可能想要处理的“逻辑级别”完全不同，因为“逻辑级别”由三种单独类型的事实断言组成：“我具有属性 p1”、“我具有属性 p2”和“我具有属性 p3”。在那个级别，您不想被这三个中的任何一个可能未知的事实所困扰。
Nulls are both "inevitable with any existing SQL engine" and "the plague and the cholera of data management all in one".
When using SQL, the key is to remember that your SQL tables are really at the level of "physical design", where you want to keep only a single record of distinct properties p1,p2,p3 of the same object, identified by some identifier I, as a single row (I,p1,p2,p3). Even if some of those properties happen to be "unknown". (I don't mention "N/A". This particular meaning exposes design flaws.)
But that SQL level is something quite distinct from the "logical level" that your application (/user) is likely to be wanting to deal with, because that "logical level" consists of three separate kinds of assertions of fact : "I has property p1", "I has property p2", and "I has property p3". At that level, you do not want to be bothered with the fact that any of the three might be unknown.