V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
edis0n0
V2EX  ›  程序员

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

  •  
  •   edis0n0 · 2022-09-08 20:35:10 +08:00 · 3280 次点击
    这是一个创建于 841 天前的主题,其中的信息可能已经有所发展或是发生改变。
    例如我们的商品描述字段,不填则显示后台设置的缺省数据。感觉是用 Nullable 更合适,不填描述直接存 null ,但是这样的话每次取值都要用 String.IsNullOrEmpty 判断一下,然后手动 cast 成 string 才能被一些函数使用。偶尔忘记判断 null 了,在复杂的逻辑中 IDE 也没报错,就会导致 500 错误。看了下 Jellyfin 等 C#的开源项目貌似用的都是 String.Empty 当缺省值。
    21 条回复    2022-09-09 13:01:43 +08:00
    thinkershare
        1
    thinkershare  
       2022-09-08 20:45:31 +08:00
    会使用, 因为有些类型必须是 Null, 数值,字节这种, null 和任何其它值都没有重叠部分, 因此实际上没得选, 你必须选择一个值来表达是真正的没有. 文本类型需要看实际, 如果需要区分 null 和'', ' ', '\r\\n'这些, 还是会使用 Nullable.
    mineralsalt
        2
    mineralsalt  
       2022-09-08 20:47:58 +08:00
    我平时大量使用 null, 因为很多数据就应该是没有的, 而不是空字符或者 0
    lujiaosama
        3
    lujiaosama  
       2022-09-08 20:55:21 +08:00
    你要是用 0, '' 来代替空值那问题更多.
    hingbong
        4
    hingbong  
       2022-09-08 21:00:32 +08:00 via Android
    看业务,业务有空值就用
    potatowish
        5
    potatowish  
       2022-09-08 21:01:40 +08:00 via iPhone
    就用 null ,用空字符就是给自己找麻烦
    dcsuibian
        6
    dcsuibian  
       2022-09-08 21:07:38 +08:00
    虽然判断麻烦点,但我倾向于保留正确的语义
    WhateverYouLike
        7
    WhateverYouLike  
       2022-09-08 21:09:23 +08:00 via Android
    建议用 null ,否则很容易引发混乱。
    最近碰到一个 config 字段:
    1. 初始是 "",用来表示此字段未设置
    2. 不允许写 null ,前端传空只能传 {}。但 {} 又是 falsy 的,导致前端判空需要多余动作...

    就特别奇怪
    TWorldIsNButThis
        8
    TWorldIsNButThis  
       2022-09-08 21:13:02 +08:00
    空值处理本来不应该成为心智负担,这也是为什么我们需要现代编程语言
    jinliming2
        9
    jinliming2  
       2022-09-08 21:39:18 +08:00 via iPhone   ❤️ 1
    @WhateverYouLike 你说的前端是 JS 吗? JS 里 {} 是 truthy 的啊,是打错了吗?
    WhateverYouLike
        10
    WhateverYouLike  
       2022-09-08 21:51:38 +08:00
    @jinliming2 是的,打错了
    lambdaq
        11
    lambdaq  
       2022-09-08 22:51:27 +08:00
    字符串,数字其实可以通过猥琐的技巧避免 null

    datetime 不得不用。。。。太蛋痛了。
    BeautifulSoap
        12
    BeautifulSoap  
       2022-09-09 00:07:32 +08:00
    空值和 null 值不是一个概念,空值和 null 的业务逻辑经常是会不同的。至于用-1 或者什么特殊数字代替 null 的,同样会有我这值就是-1 的话该怎么办的问题。所以 null 经常是必须的
    littlewing
        13
    littlewing  
       2022-09-09 00:16:21 +08:00
    大胆地用,不要相信网上那些千篇一律的抄的文章说有 NULL 不能用索引,查询效率低等,纯属胡扯
    nothingistrue
        14
    nothingistrue  
       2022-09-09 01:56:18 +08:00
    字符串可以用空字符串代替 NULL ,只要全局约定好即可。但是还是不如不区分 null 或 empty ,统一使用 StrUtil.isEmpty/isNotEmpty 来判断更好。因为有些数据库,比如 Oracle ,它本身是不区分 char/varchar 类型列的 null 和 空白的(这些列 column is null 跟 column = '' 总是返回相同结果)。null 字符串的显示,确实不好处理,但这是纯 UI 层次的问题,ORM 层不应该考虑。

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

    如果业务上应该有默认值,最好还是以默认值代替 NULL 。但是记住,这是业务逻辑的要求,不是性能的要求。现行数据库( Mysql 除外),基本都不会因为 NULL 值影响性能。
    hezhiming1993
        15
    hezhiming1993  
       2022-09-09 08:00:57 +08:00 via Android
    搞了很多中大型模块,基本不用 null
    hay313955795
        16
    hay313955795  
       2022-09-09 08:26:51 +08:00
    springboot 字段是 null 的话 返回给前端的 数据里连这个字段的 key 都会隐藏了.
    lmshl
        17
    lmshl  
       2022-09-09 08:31:53 +08:00
    我用的语言里要么支持 Maybe T ,Option[T],Option<T> ( Haskell/Scala/Rust
    要么支持 T?( Kotlin ,TypeScript
    所以 ORM 想用 null 就用 null ,完全不操心 NPE
    loolac
        18
    loolac  
       2022-09-09 08:48:09 +08:00
    建议约定零值。null 在排序上就是个麻烦,因为编程语言里面和 null 和 其它类型混合排序和数据库中的 null 混合排序大概需要一点点去实践和判断,不同数据库有不一样的做法,这才是最麻烦的,一些常用的比较运算也不适用 null 值,这会使查询条件复杂化,不利于查询优化。
    YUyu101
        19
    YUyu101  
       2022-09-09 09:14:24 +08:00   ❤️ 1
    本来就应该是 null 的,以为省事其实最后都会还回去
    Leviathann
        20
    Leviathann  
       2022-09-09 09:38:16 +08:00
    约定空值,那代码里还得时刻记得判断一下是不是约定值?还是说每个类都手写一个反序列化转换?
    kzzhr
        21
    kzzhr  
       2022-09-09 13:01:43 +08:00 via Android
    10 亿美金的错误
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   918 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 22:16 · PVG 06:16 · LAX 14:16 · JFK 17:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.