V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Renco
V2EX  ›  程序员

数据库表设计是否需要在字段前标注字段的所属对象,比如用户表的名字是 user_name,学校表的名字字段是 school_name

  •  2
     
  •   Renco · 2021-04-14 22:06:57 +08:00 · 7530 次点击
    这是一个创建于 1079 天前的主题,其中的信息可能已经有所发展或是发生改变。

    这样写法会不会过于冗余。

    102 条回复    2021-04-17 11:43:36 +08:00
    1  2  
    feifanhanmc
        1
    feifanhanmc  
       2021-04-14 22:09:13 +08:00 via iPhone
    目前在用的一套感觉比较好的命名规范
    nam_school
    nam_user
    cod_sex
    vlu_mail
    num_phone
    dethan
        2
    dethan  
       2021-04-14 22:09:31 +08:00 via Android
    写也行,不写也行。没人说不好,也没人说好。
    Renco
        3
    Renco  
    OP
       2021-04-14 22:11:39 +08:00
    @dethan 行把
    zoharSoul
        4
    zoharSoul  
       2021-04-14 22:30:30 +08:00   ❤️ 2
    @feifanhanmc 这都啥奇奇怪怪的缩写
    David1119
        5
    David1119  
       2021-04-14 22:34:03 +08:00   ❤️ 45
    @feifanhanmc 哪来的自信觉得好?少写一个字母是什么鬼???
    feifanhanmc
        6
    feifanhanmc  
       2021-04-14 23:08:55 +08:00 via iPhone
    @David1119 这叫奇怪的缩写?麻瓜
    liprais
        7
    liprais  
       2021-04-14 23:26:39 +08:00 via iPhone
    表名不是干这个用的么
    oott123
        8
    oott123  
       2021-04-14 23:35:45 +08:00
    @feifanhanmc 关于 1 楼提到的缩写,nam 应该是 name,num 是 number,这都没问题。可是 cod 和 vlu 分别是什么的缩写呢?我想了很久都没想出来,能否指点一下。
    tyx1703
        9
    tyx1703  
       2021-04-14 23:39:01 +08:00
    @oott123 code, value
    SuperMild
        10
    SuperMild  
       2021-04-14 23:39:51 +08:00   ❤️ 1
    完全没必要,可以用 user.nameschool.name 来区分。

    不太懂用 user_name 和 school_name 有什么好处。
    GuoGuang
        11
    GuoGuang  
       2021-04-14 23:56:30 +08:00   ❤️ 4
    @feifanhanmc 你这漏几个字母我觉得比拼音都离谱,lear_record 、ou_log
    zidian
        12
    zidian  
       2021-04-15 00:07:53 +08:00 via iPhone
    从来不加。
    而且很迷的一件事,好像只有 id code name 爱加上表名,其他比如 age sex 就从没见过人加。
    Chieh
        13
    Chieh  
       2021-04-15 00:09:17 +08:00
    @feifanhanmc 为了“简化”英文少了拼写,导致懂英文的和不懂英文的都看不懂
    c6h6benzene
        14
    c6h6benzene  
       2021-04-15 00:15:25 +08:00   ❤️ 1
    @zidian #12 因为这几个字段所有表都可能有,字段名写上表名 Join 的时候不会错。Join 时候别名一加,就不一定知道 u.nameuser.name 还是什么的 name 了。
    ipwx
        15
    ipwx  
       2021-04-15 00:21:45 +08:00
    @c6h6benzene u.name 不就隐含 user.name 么,根据上下文都能知道。再不济到时候用 user.name 它不香嘛。。。

    等等,除非你为了取出来到 php 里面的时候可以 select * ...
    c6h6benzene
        16
    c6h6benzene  
       2021-04-15 00:53:57 +08:00
    @ipwx #15 这不就是为了防止 user 和 unit 这种都是 U 开头的😂SQL JOIN 多的时候,ID 前面不加前缀我都想骂人
    baobao1270
        17
    baobao1270  
       2021-04-15 02:04:15 +08:00 via Android
    不加
    反正 ORM 帮我搞定,现在几乎不怎么写 sql 了
    neoblackcap
        18
    neoblackcap  
       2021-04-15 04:00:44 +08:00
    如果你用的是关系型数据库,那么你这个做法就是反模式。毕竟关系型数据库讲究数据模型正交。
    stabc
        19
    stabc  
       2021-04-15 04:04:38 +08:00
    我倾向于不加前缀
    kchum
        20
    kchum  
       2021-04-15 07:01:14 +08:00
    不加. 连表有也有表名在前面, 用 Alias 出错也只能怪自己
    morimi2026
        21
    morimi2026  
       2021-04-15 07:07:14 +08:00 via iPhone   ❤️ 30
    @feifanhanmc 这是我见过的最差的命名规范
    ColouredGlaze
        22
    ColouredGlaze  
       2021-04-15 07:21:40 +08:00
    name 是 mysql 数据库的保留字,个人建议是数据库字段加上前缀,代码实体去掉前缀,映射做好,个人建议
    raaaaaar
        23
    raaaaaar  
       2021-04-15 07:41:43 +08:00 via Android
    id 你们也加吗?但是 gorm 这种框架会自动加一个 id 字段,需要额外弄么。。
    iseki
        24
    iseki  
       2021-04-15 07:57:02 +08:00 via Android
    不用
    VeryZero
        25
    VeryZero  
       2021-04-15 08:33:51 +08:00
    个人不喜欢加,但是公司要求加。。

    因为很多表名本身就自带前缀,字段名再加表名前缀,这是在套娃吗。字段名冲突用别名解决不香吗。

    另外坚决反对缩写的,少一两个字符又不会影响数据库性能,是想让别人觉得你很厉害吗?

    程序里面也是同理,有些人就喜欢整各种稀奇古怪的缩写变量名,方法名。生怕别人不知道这坨屎是谁拉的。
    masterclock
        26
    masterclock  
       2021-04-15 08:36:46 +08:00   ❤️ 4
    @feifanhanmc 这是我见过的最差的命名规范
    sutra
        27
    sutra  
       2021-04-15 08:40:14 +08:00
    如果字段名都需要用表名做前缀,那还需要表干什么?
    statement
        28
    statement  
       2021-04-15 08:40:20 +08:00
    原表不加 但关联表肯定要加 不然同一张表不两个 id 和 name
    encro
        29
    encro  
       2021-04-15 08:41:35 +08:00
    表名就可以表示自身了,所以没必要加前缀,除非外键 order.user_id 这样的
    siweipancc
        30
    siweipancc  
       2021-04-15 08:55:34 +08:00 via iPhone
    挺可怕的,一言不合就骂人:D
    TimPeake
        31
    TimPeake  
       2021-04-15 08:57:12 +08:00
    😂
    xuanbg
        32
    xuanbg  
       2021-04-15 08:57:34 +08:00
    不加,我手写 sql 也不加。
    rationa1cuzz
        33
    rationa1cuzz  
       2021-04-15 09:04:34 +08:00
    考虑到 join 的情况我是都是用 xx_name,其实可以起别名,但是某些情况下不好写(狗头)
    IvanLi127
        34
    IvanLi127  
       2021-04-15 09:06:37 +08:00 via Android
    完全没必要,因为库里这冗余的命名,前后端业务、接口、界面都得多写这些。表加这个是不会用 sql 的 alias 么?不写不会影响产出质量
    wangritian
        35
    wangritian  
       2021-04-15 09:34:54 +08:00
    我觉得没必要带,同理包括 api 接口设计
    PerFectTime
        36
    PerFectTime  
       2021-04-15 09:37:09 +08:00
    外键才会加上描述
    对应实体中的属性不加
    passerbytiny
        37
    passerbytiny  
       2021-04-15 10:02:27 +08:00 via Android   ❤️ 2
    (古老的,或者大型的)数据库设计体系, “列”是直属于数据库,而不是先属于“表”再间接属于数据库的,这样列名必须要能自举。在以前那种到处是“review”,甚至用存储过程代替应用编程的时候,这种从全局层面管理列的架构,应该是有好处的。

    后来因为 ORM,或者是回归原始的关系数据模型,列(属性 /字段),只能从属于表(实体 /类)了,列名是否能自举,就不再重要了。

    然而以上那些只是副因,如何命名,主要还是取决于开发人 /团队的自制规范。
    clf
        38
    clf  
       2021-04-15 10:04:18 +08:00
    加前缀的好处就是避免有些运维直接手写 sql 时忘了加反引号,比如 name 是 sql 的关键字,一些情况下不加反引号就会报错。当然咯,如果全部操作都是在 IDE 和 ORM 框架下操作的,不需要手写 SQL,就没这个问题。

    不过一般情况下,外部数据才会加前缀,本体属性不会加前缀。
    Outshine
        39
    Outshine  
       2021-04-15 10:06:43 +08:00   ❤️ 1
    找不到这样写的必要,join 的时候 table.name 不就行了?

    ----

    我们这边的习惯就是只有外键会加表名,比如文章表的作者 ID 和分类 ID:creator_id 、category_id

    ---

    另外,#1 @feifanhanmc 的那个命名规范简直烂透了
    cheng6563
        40
    cheng6563  
       2021-04-15 10:14:29 +08:00
    我司是如
    SCHL_NAME
    SCHL_ADDR
    SCHL_CICO
    SCHL_CINA
    chendy
        41
    chendy  
       2021-04-15 10:16:07 +08:00
    不加,加了之后反而要写成 school.school_name 就很麻烦
    angeloce
        42
    angeloce  
       2021-04-15 10:19:01 +08:00
    像 id 这种代表数据的唯一主键,考虑到数据流转时各方的理解,是应该加上前缀的而且是全局唯一前缀。 命名常见的字段,如果能考虑到流转时关联表合并、数据层级被打平,也应该加上。
    jucelin
        43
    jucelin  
       2021-04-15 10:35:39 +08:00
    如果以后要用 BI,建议写全,特别是 Key,这样 BI 可以自动匹配关系。
    user.user_id 要比 user.id 好。

    另外,编辑器已经实现代码提示,不用在乎长,可读性反而更重要。
    barbery
        44
    barbery  
       2021-04-15 10:41:28 +08:00
    这样写法会不会过于冗余。
    =====
    不会
    l00t
        45
    l00t  
       2021-04-15 10:47:37 +08:00
    加。
    kkkkkrua
        46
    kkkkkrua  
       2021-04-15 10:50:15 +08:00
    加不加都可,但是碰到明明是数据库的关键字,就得加上了,比如 type
    frankfang1995
        47
    frankfang1995  
       2021-04-15 10:57:20 +08:00   ❤️ 1
    @feifanhanmc 性别能不能别用 sex,gender 懂不懂?
    dayudayupao
        48
    dayudayupao  
       2021-04-15 11:00:58 +08:00   ❤️ 1
    @feifanhanmc 你这个是真看不懂,你确定是比较好的命名规范? 就你自己看的懂吧
    aitaii
        49
    aitaii  
       2021-04-15 11:02:39 +08:00   ❤️ 3
    目前在用的一套感觉比较好的命名规范
    n_sol
    n_ur
    cd_sx
    vu_ail
    nu_pne
    dayudayupao
        50
    dayudayupao  
       2021-04-15 11:04:10 +08:00   ❤️ 2
    @feifanhanmc 看了这么多评论都是喷你的就舒服了,你这些典型的自己菜还嘴臭
    dayudayupao
        51
    dayudayupao  
       2021-04-15 11:04:56 +08:00
    @aitaii 好的,马上拿去用
    limuyan44
        52
    limuyan44  
       2021-04-15 11:05:10 +08:00
    school.schoolname 会不会很奇怪。
    romisanic
        53
    romisanic  
       2021-04-15 11:06:33 +08:00
    当前对象表里如果用到了关联其他对象的一些字段,就加上对象名
    比如学生表里要加班级 ID,那就叫 class_id,但是学生自己的 ID 就叫 id
    同样反过来,如果课程对象要用到学生的 ID 的时候,也应该叫 student_id
    dayudayupao
        54
    dayudayupao  
       2021-04-15 11:09:12 +08:00
    我个人觉得是不加好, 已经有表名区分了
    lzj307077687
        55
    lzj307077687  
       2021-04-15 11:25:06 +08:00
    我不加 复制粘贴可以少改几行
    chenmobuys
        56
    chenmobuys  
       2021-04-15 11:28:27 +08:00
    尽量别用数据库保留字段,加好备注,随你怎么取名
    nekoneko
        57
    nekoneko  
       2021-04-15 11:54:44 +08:00   ❤️ 3
    向一楼学习,目前没用以后也不会用的一套感觉比较好的命名规范
    n_s
    n_u
    c_s
    v_a
    n_p

    个人不习惯 user_name 这样的命名方式
    user 表已经说明问题了
    gawoo
        58
    gawoo  
       2021-04-15 12:07:37 +08:00
    @nekoneko 你这个厉害
    feifanhanmc
        59
    feifanhanmc  
       2021-04-15 12:10:56 +08:00 via iPhone
    @frankfang1995 #46 笑了这也能杠
    feifanhanmc
        60
    feifanhanmc  
       2021-04-15 12:13:07 +08:00 via iPhone
    @dayudayupao #49 呦,来这里找优越感啦
    AlexWIT
        61
    AlexWIT  
       2021-04-15 12:33:59 +08:00   ❤️ 6
    @feifanhanmc 笑拉了,没十年脑血栓想不出来这缩写
    no1xsyzy
        62
    no1xsyzy  
       2021-04-15 12:35:10 +08:00
    @feifanhanmc 匈牙利命名法复刻,没想到这里还能看到不识好歹的
    WilliamYang
        63
    WilliamYang  
       2021-04-15 12:58:27 +08:00 via iPhone
    代码整洁之道,多看看书,你就会有答案了
    morimi2026
        64
    morimi2026  
       2021-04-15 13:01:51 +08:00
    @feifanhanmc 命名要避免非通用的缩写,这样才有可读性。可读性高就维护起来就容易。
    star7th
        65
    star7th  
       2021-04-15 13:53:50 +08:00
    建议写,方便一眼看出这是什么字段。
    Rwing
        66
    Rwing  
       2021-04-15 13:57:23 +08:00   ❤️ 1
    不加,另外一楼真的笑到我了
    ychost
        67
    ychost  
       2021-04-15 14:00:52 +08:00
    不加,join 的时候 as 一下就好了
    deepmindlab
        68
    deepmindlab  
       2021-04-15 14:04:26 +08:00   ❤️ 1
    @feifanhanmc 这命名规范比我今天的粑粑还臭
    newtype0092
        69
    newtype0092  
       2021-04-15 14:09:06 +08:00   ❤️ 1
    @feifanhanmc V2 点赞功能太不人性化了,自己的点赞有提醒,别人喷自己的点赞却没有,这样想一个一个喷回去太麻烦了,咱们一起给站长提建议加上这个功能吧🐶
    tairan2006
        70
    tairan2006  
       2021-04-15 14:09:42 +08:00
    不用加,不过如果是为了避免数据库的保留字,可以加前缀
    weiwenhao
        71
    weiwenhao  
       2021-04-15 14:12:59 +08:00
    建议都加上前缀,下面推荐一些好的写法


    建议 map 字段命名:
    public $publibUser = [
    $userStringPublicName => "xxx",
    $userIntPublicSex => 12,
    $userIntPublicId => 1,
    ]

    建议类命名
    class User {

    public PublicObjectUserInfo() {}
    public PublicArrayUserList() {}
    public PublicVoidUserUpdate {}
    public PublicVoidUserCreate {}
    public PublicVoidUserDelete {}
    private _VoidAddUserSex{}
    }

    建议接口命名
    api/users/12/user_posts (获取用户文章)

    api/products/12/product_comments (获取商品评论)
    caixiaomao
        72
    caixiaomao  
       2021-04-15 14:13:33 +08:00
    没必要 一般表名会体现 但是在关联表之类的会加上
    CantSee
        73
    CantSee  
       2021-04-15 14:17:46 +08:00
    我们一般都是固定的:比如活动表.是一个固定前缀加英文 XXX_ACTIVE_BASE, 如果是活动条件表就是 XXX_ACTIVE_LIMIT
    wupher
        74
    wupher  
       2021-04-15 14:54:08 +08:00
    一般不需要。

    除非你进行的是超大型项目,类似运营商 CRM 这类。表结构大,数据多,未来会上 N 多个 BI 、分析系统,主表如用户或者交易还经常会被各种联表、过程进行查询。上述情况,推荐添加。实际上,电信以及相应厂商的规范里面也写的很清楚。

    正常一般应用,我是觉得 User.name 比 user.userName 好多了。
    lvtuyukuai
        75
    lvtuyukuai  
       2021-04-15 15:26:58 +08:00   ❤️ 1
    1 楼赶紧回 M78 星云吧,地球已经没有怪兽了。
    way2create
        76
    way2create  
       2021-04-15 15:37:27 +08:00
    个人不喜欢加 特别是 id
    ipwx
        77
    ipwx  
       2021-04-15 15:41:22 +08:00
    @c6h6benzene 如果只是 join,那么别名用 unit & user 不就行了。。。
    dayudayupao
        78
    dayudayupao  
       2021-04-15 15:49:49 +08:00
    一楼要是不骂人麻瓜,我觉得作为一种讨论倒也没什么,都是互相学习过来的,关键是自己滂臭的命名别人反驳一下都不行....
    id4alex
        79
    id4alex  
       2021-04-15 15:51:27 +08:00
    好处是以你眼就可以看出来这个字段是来自哪个表, 坏处是太啰嗦.

    大家一起权衡
    lithiumii
        80
    lithiumii  
       2021-04-15 16:02:55 +08:00
    用户表 user
    name, school_name, ...

    学校表 school
    name, ...

    某个不知道啥既有用户又有学校的表
    user_name, school_name, ...
    knightdf
        81
    knightdf  
       2021-04-15 16:16:29 +08:00
    没必要加,表名单数形式,字段直接属性名就可以了,不用前缀
    raycool
        82
    raycool  
       2021-04-15 17:01:35 +08:00
    一楼这命名真的太差了。
    caroline1022
        83
    caroline1022  
       2021-04-15 17:12:52 +08:00
    我个人倾向于当某表在大部分使用场景下都是联合查询的时候,会在前面加前缀,以免有的时候要从 entity 转成 view 返回给前端的时候无法使用统一写好的属性赋值工具而必须手动 set
    lazyDaddy
        84
    lazyDaddy  
       2021-04-15 17:25:03 +08:00   ❤️ 1
    一楼笑死了
    nobodyknows
        85
    nobodyknows  
       2021-04-15 18:42:36 +08:00
    一时间不知道一楼是不是认真的。
    huijiewei
        86
    huijiewei  
       2021-04-15 19:00:06 +08:00
    为什么要加

    要不把数据库名字也加上,跨库查询也是需要的嘛
    cp19890714
        87
    cp19890714  
       2021-04-15 19:02:14 +08:00
    user 表
    id
    name

    school 表
    id
    name

    如果这些字段在其他表中使用则 user_id user_name school_id school_name
    zxCoder
        88
    zxCoder  
       2021-04-15 19:05:41 +08:00
    @masterclock cod 和 vlu 我是真没见过。。。。
    cloudzhou
        89
    cloudzhou  
       2021-04-15 19:32:46 +08:00   ❤️ 1
    @feifanhanmc 这缩写简直莫名其妙,我一向建议,长点就长点,可读性好就可以
    strive
        90
    strive  
       2021-04-15 19:50:24 +08:00   ❤️ 1
    @feifanhanmc 说真的,这命名没眼看
    lvdb
        91
    lvdb  
       2021-04-15 20:42:37 +08:00 via Android   ❤️ 1
    #1L 大亚心了,blk 了
    lvdb
        92
    lvdb  
       2021-04-15 20:46:02 +08:00 via Android   ❤️ 1
    1L 简直也马彳业母瘤啊
    young1lin
        93
    young1lin  
       2021-04-15 20:53:00 +08:00   ❤️ 1
    1L 在教坏新手,这特么缩写就少了一个字母,你当是 HBase 呢,colunm name 要尽量简短,普通的 RDBMS 就直接用对应的名称就行了。不要写成 school_name,直接写 name 就行了,除非是在中间表,或者其他的表中,作为外键(实际开发不用外键)的存在时候,就要写成 school_name 。尽量见明知意,除非你是用的 HBase 这种,或者其他对字段长度有比较大的优化要求的数据库。
    hyqCrystal
        94
    hyqCrystal  
       2021-04-15 21:07:23 +08:00
    看个人习惯 我喜欢加
    noyidoit
        95
    noyidoit  
       2021-04-15 21:52:23 +08:00
    @nekoneko 你这和表情符号似的
    seakingii
        96
    seakingii  
       2021-04-15 22:36:47 +08:00
    我会加.

    我认为表名字段名长一点没关系,直观识别意义比较重要.
    towry
        97
    towry  
       2021-04-15 22:46:27 +08:00
    > To make your code more readable, it is better to have your code be explicit (that is, clearly state something even if it might be obvious) rather than implicit (that is, leaving it up to the person reading code to know how it works without outright telling them).

    想屏蔽 1L 那样的人
    codingadog
        98
    codingadog  
       2021-04-15 22:52:57 +08:00 via Android
    一楼老魔法师了🤣
    listenerri
        99
    listenerri  
       2021-04-16 09:00:34 +08:00
    我也喜欢加
    nekoneko
        100
    nekoneko  
       2021-04-16 12:31:15 +08:00
    @noyidoit #95 仔细一看还真是😄
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1307 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 79ms · UTC 23:31 · PVG 07:31 · LAX 16:31 · JFK 19:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.