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

[edis0n0]

例如我们的商品描述字段，不填则显示后台设置的缺省数据。感觉是用 Nullable 更合适，不填描述直接存 null ，但是这样的话每次取值都要用 String.IsNullOrEmpty 判断一下，然后手动 cast 成 string 才能被一些函数使用。偶尔忘记判断 null 了，在复杂的逻辑中 IDE 也没报错，就会导致 500 错误。看了下 Jellyfin 等 C#的开源项目貌似用的都是 String.Empty 当缺省值。

[thinkershare]

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

[mineralsalt]

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

[lujiaosama]

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

[hingbong]

看业务，业务有空值就用

[potatowish]

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

[dcsuibian]

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

[WhateverYouLike]

建议用 null ，否则很容易引发混乱。
最近碰到一个 config 字段：
1. 初始是 ""，用来表示此字段未设置
2. 不允许写 null ，前端传空只能传 {}。但 {} 又是 falsy 的，导致前端判空需要多余动作...

就特别奇怪

[TWorldIsNButThis]

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

[jinliming2]

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

[WhateverYouLike]

@jinliming2 是的，打错了

[lambdaq]

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

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

[BeautifulSoap]

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

[littlewing]

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

[nothingistrue]

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

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

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

[hezhiming1993]

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

[hay313955795]

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

[lmshl]

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

[loolac]

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

[YUyu101]

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

[Leviathann]

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