你们数据库 ORM 框架可选字段会设计成 Nullable 吗？

会使用, 因为有些类型必须是 Null, 数值,字节这种, null 和任何其它值都没有重叠部分, 因此实际上没得选, 你必须选择一个值来表达是真正的没有. 文本类型需要看实际, 如果需要区分 null 和'', ' ', '\r\\n'这些, 还是会使用 Nullable.

我平时大量使用 null, 因为很多数据就应该是没有的, 而不是空字符或者 0

你要是用 0, '' 来代替空值那问题更多.

看业务，业务有空值就用

就用 null ，用空字符就是给自己找麻烦

虽然判断麻烦点，但我倾向于保留正确的语义

空值处理本来不应该成为心智负担，这也是为什么我们需要现代编程语言

@WhateverYouLike 你说的前端是 JS 吗？ JS 里 {} 是 truthy 的啊，是打错了吗？

@jinliming2 是的，打错了

字符串，数字其实可以通过猥琐的技巧避免 null

datetime 不得不用。。。。太蛋痛了。

空值和 null 值不是一个概念，空值和 null 的业务逻辑经常是会不同的。至于用-1 或者什么特殊数字代替 null 的，同样会有我这值就是-1 的话该怎么办的问题。所以 null 经常是必须的

大胆地用，不要相信网上那些千篇一律的抄的文章说有 NULL 不能用索引，查询效率低等，纯属胡扯

字符串可以用空字符串代替 NULL ，只要全局约定好即可。但是还是不如不区分 null 或 empty ，统一使用 StrUtil.isEmpty/isNotEmpty 来判断更好。因为有些数据库，比如 Oracle ，它本身是不区分 char/varchar 类型列的 null 和 空白的（这些列 column is null 跟 column = '' 总是返回相同结果）。null 字符串的显示，确实不好处理，但这是纯 UI 层次的问题，ORM 层不应该考虑。

非字符串类型，那就不用说了，如果没有默认值，那就必须提供 NULL。

如果业务上应该有默认值，最好还是以默认值代替 NULL 。但是记住，这是业务逻辑的要求，不是性能的要求。现行数据库（ Mysql 除外），基本都不会因为 NULL 值影响性能。

搞了很多中大型模块，基本不用 null

springboot 字段是 null 的话 返回给前端的 数据里连这个字段的 key 都会隐藏了.

我用的语言里要么支持 Maybe T ，Option[T]，Option<T> （ Haskell/Scala/Rust
要么支持 T?（ Kotlin ，TypeScript
所以 ORM 想用 null 就用 null ，完全不操心 NPE

建议约定零值。null 在排序上就是个麻烦，因为编程语言里面和 null 和 其它类型混合排序和数据库中的 null 混合排序大概需要一点点去实践和判断，不同数据库有不一样的做法，这才是最麻烦的，一些常用的比较运算也不适用 null 值，这会使查询条件复杂化，不利于查询优化。

本来就应该是 null 的，以为省事其实最后都会还回去

约定空值，那代码里还得时刻记得判断一下是不是约定值？还是说每个类都手写一个反序列化转换？

10 亿美金的错误