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

• 資深大佬 : feifanhanmc

  目前在用的一套感觉比较好的命名规范
  nam_school
  nam_user
  cod_sex
  vlu_mail
  num_phone

• 資深大佬 : dethan

  写也行，不写也行。没人说不好，也没人说好。

• 主 資深大佬 : Renco

  @dethan 行把

• 資深大佬 : zoharSoul

  @feifanhanmc 这都啥奇奇怪怪的缩写

• 資深大佬 : David1119

  @feifanhanmc 哪来的自信觉得好？少写一个字母是什么鬼？？？

• 資深大佬 : feifanhanmc

  @David1119 这叫奇怪的缩写？麻瓜

• 資深大佬 : liprais

  表名不是干这个用的么

• 資深大佬 : oott123

  @feifanhanmc 关于 1 提到的缩写，nam 应该是 name，num 是 number，这都没问题。可是 cod 和 vlu 分别是什么的缩写呢？我想了很久都没想出来，能否指点一下。

• 資深大佬 : tyx1703

  @oott123 code, value

• 資深大佬 : SuperMild

  完全没必要，可以用 user.name 和 school.name 来区分。

  不太懂用 user_name 和 school_name 有什么好处。

• 資深大佬 : GuoGuang

  @feifanhanmc 你这漏几个字母我觉得比拼音都离谱，lear_record 、ou_log

• 資深大佬 : zidian

  从来不加。
  而且很迷的一件事，好像只有 id code name 爱加上表名，其他比如 age sex 就从没见过人加。

• 資深大佬 : Chieh

  @feifanhanmc 为了“简化”英文少了拼写，导致懂英文的和不懂英文的都看不懂

• 資深大佬 : c6h6benzene

  @zidian #12 因为这几个字段所有表都可能有，字段名写上表名 Join 的时候不会错。Join 时候别名一加，就不一定知道 u.name 是 user.name 还是什么的 name 了。

• 資深大佬 : ipwx

  @c6h6benzene u.name 不就隐含 user.name 么，根据上下文都能知道。再不济到时候用 user.name 它不香嘛。。。

  等等，除非你为了取出来到 php 里面的时候可以 select * …

• 資深大佬 : c6h6benzene

  @ipwx #15 这不就是为了防止 user 和 unit 这种都是 U 开头的

• 資深大佬 : baobao1270

  不加
  反正 ORM 帮我搞定，现在几乎不怎么写 sql 了

• 資深大佬 : neoblackcap

  如果你用的是关系型数据库，那么你这个做法就是反模式。毕竟关系型数据库讲究数据模型正交。

• 資深大佬 : stabc

  我倾向于不加前缀

• 資深大佬 : kchum

  不加. 连表有也有表名在前面, 用 Alias 出错也只能怪自己

• 資深大佬 : morimi2026

  @feifanhanmc 这是我见过的最差的命名规范

• 資深大佬 : ColouredGlaze

  name 是 mysql 数据库的保留字，个人建议是数据库字段加上前缀，代码实体去掉前缀，映射做好，个人建议

• 資深大佬 : raaaaaar

  id 你们也加吗？但是 gorm 这种框架会自动加一个 id 字段，需要额外弄么。。

• 資深大佬 : iseki

  不用

• 資深大佬 : VeryZero

  个人不喜欢加，但是公司要求加。。

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

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

  程序里面也是同理，有些人就喜欢整各种稀奇古怪的缩写变量名，方法名。生怕别人不知道这坨屎是谁拉的。

• 資深大佬 : masterclock

  @feifanhanmc 这是我见过的最差的命名规范

• 資深大佬 : sutra

  如果字段名都需要用表名做前缀，那还需要表干什么？

• 資深大佬 : statement

  原表不加 但关联表肯定要加 不然同一张表不两个 id 和 name

• 資深大佬 : encro

  表名就可以表示自身了，所以没必要加前缀，除非外键 order.user_id 这样的

• 資深大佬 : siweipancc

  挺可怕的，一言不合就骂人:D

• 資深大佬 : TimPeake

• 資深大佬 : xuanbg

  不加，我手写 sql 也不加。

• 資深大佬 : rationa1cuzz

  考虑到 join 的情况我是都是用 xx_name，其实可以起别名，但是某些情况下不好写(狗头)

• 資深大佬 : IvanLi127

  完全没必要，因为库里这冗余的命名，前后端业务、接口、界面都得多写这些。表加这个是不会用 sql 的 alias 么？不写不会影响产出质量

• 資深大佬 : wangritian

  我觉得没必要带，同理包括 api 接口设计

• 資深大佬 : PerFectTime

  外键才会加上描述
  对应实体中的属性不加

• 資深大佬 : passerbytiny

  （古老的，或者大型的）数据库设计体系， “列”是直属于数据库，而不是先属于“表”再间接属于数据库的，这样列名必须要能自举。在以前那种到处是“review”，甚至用存储过程代替应用编程的时候，这种从全局层面管理列的架构，应该是有好处的。

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

  然而以上那些只是副因，如何命名，主要还是取决于开发人 /团队的自制规范。

• 資深大佬 : lychs1998

  加前缀的好处就是避免有些运维直接手写 sql 时忘了加反引号，比如 name 是 sql 的关键字，一些情况下不加反引号就会报错。当然咯，如果全部操作都是在 IDE 和 ORM 框架下操作的，不需要手写 SQL，就没这个问题。

  不过一般情况下，外部数据才会加前缀，本体属性不会加前缀。

• 資深大佬 : Outshine

  找不到这样写的必要，join 的时候 table.name 不就行了？

  —-

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

  —

  另外，#1 @feifanhanmc 的那个命名规范简直烂透了

• 資深大佬 : cheng6563

  我司是如
  SCHL_NAME
  SCHL_ADDR
  SCHL_CICO
  SCHL_CINA

• 資深大佬 : chendy

  不加，加了之后反而要写成 school.school_name 就很麻烦

• 資深大佬 : angeloce

  像 id 这种代表数据的唯一主键，考虑到数据流转时各方的理解，是应该加上前缀的而且是全局唯一前缀。 命名常见的字段，如果能考虑到流转时关联表合并、数据层级被打平，也应该加上。

• 資深大佬 : jucelin

  如果以后要用 BI，建议写全，特别是 Key，这样 BI 可以自动匹配关系。
  user.user_id 要比 user.id 好。

  另外，编辑器已经实现代码提示，不用在乎长，可读性反而更重要。

• 資深大佬 : barbery

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

• 資深大佬 : l00t

  加。

• 資深大佬 : kkkkkrua

  加不加都可，但是碰到明明是数据库的关键字，就得加上了，比如 type

• 資深大佬 : frankfang1995

  @feifanhanmc 性别能不能别用 sex，gender 懂不懂？

• 資深大佬 : dayudayupao

  @feifanhanmc 你这个是真看不懂,你确定是比较好的命名规范? 就你自己看的懂吧

• 資深大佬 : aitaii

  目前在用的一套感觉比较好的命名规范
  n_sol
  n_ur
  cd_sx
  vu_ail
  nu_pne
• 資深大佬 : dayudayupao

  @feifanhanmc 看了这么多评论都是喷你的就舒服了,你这些典型的自己菜还嘴臭

• 資深大佬 : dayudayupao

  @aitaii 好的,马上拿去用

• 資深大佬 : limuyan44

  school.schoolname 会不会很奇怪。

• 資深大佬 : romisanic

  当前对象表里如果用到了关联其他对象的一些字段，就加上对象名
  比如学生表里要加班级 ID，那就叫 class_id，但是学生自己的 ID 就叫 id
  同样反过来，如果课程对象要用到学生的 ID 的时候，也应该叫 student_id

• 資深大佬 : dayudayupao

  我个人觉得是不加好, 已经有表名区分了

• 資深大佬 : lzj307077687

  我不加 复制粘贴可以少改几行

• 資深大佬 : chenmobuys

  尽量别用数据库保留字段，加好备注，随你怎么取名

• 資深大佬 : nekoneko

  向一学习,目前没用以后也不会用的一套感觉比较好的命名规范
  n_s
  n_u
  c_s
  v_a
  n_p

  个人不习惯 user_name 这样的命名方式
  user 表已经说明问题了

• 資深大佬 : gawoo

  @nekoneko 你这个厉害

• 資深大佬 : feifanhanmc

  @frankfang1995 #46 笑了这也能杠

• 資深大佬 : feifanhanmc

  @dayudayupao #49 呦，来这里找优越感啦

• 資深大佬 : AlexWIT

  @feifanhanmc 笑拉了，没十年脑血栓想不出来这缩写

• 資深大佬 : no1xsyzy

  @feifanhanmc 匈牙利命名法复刻，没想到这里还能看到不识好歹的

• 資深大佬 : WilliamYang

  代码整洁之道，多看看书，你就会有答案了

• 資深大佬 : morimi2026

  @feifanhanmc 命名要避免非通用的缩写，这样才有可读性。可读性高就维护起来就容易。

• 資深大佬 : star7th

  建议写，方便一眼看出这是什么字段。

• 資深大佬 : Rwing

  不加，另外一真的笑到我了

• 資深大佬 : ychost

  不加，join 的时候 as 一下就好了

• 資深大佬 : deepmindlab

  @feifanhanmc 这命名规范比我今天的粑粑还臭

• 資深大佬 : newtype0092

  @feifanhanmc V2 点赞功能太不人性化了，自己的点赞有提醒，别人喷自己的点赞却没有，这样想一个一个喷回去太麻烦了，咱们一起给站长提建议加上这个功能吧

• 資深大佬 : tairan2006

  不用加，不过如果是为了避免数据库的保留字，可以加前缀

• 資深大佬 : weiwenhao

  建议都加上前缀，下面推荐一些好的写法

  建议 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

  没必要 一般表名会体现 但是在关联表之类的会加上

• 資深大佬 : CantSee

  我们一般都是固定的:比如活动表.是一个固定前缀加英文 XXX_ACTIVE_BASE, 如果是活动条件表就是 XXX_ACTIVE_LIMIT

• 資深大佬 : wupher

  一般不需要。

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

  正常一般应用，我是觉得 User.name 比 user.userName 好多了。

• 資深大佬 : lvtuyukuai

  1 赶紧回 M78 星云吧，地球已经没有怪兽了。

• 資深大佬 : way2create

  个人不喜欢加 特别是 id

• 資深大佬 : ipwx

  @c6h6benzene 如果只是 join，那么别名用 unit & user 不就行了。。。

• 資深大佬 : dayudayupao

  一要是不骂人麻瓜,我觉得作为一种讨论倒也没什么,都是互相学习过来的,关键是自己滂臭的命名别人反驳一下都不行….

• 資深大佬 : id4alex

  好处是以你眼就可以看出来这个字段是来自哪个表, 坏处是太啰嗦.

  大家一起权衡

• 資深大佬 : lithiumii

  用户表 user
  name, school_name, …

  学校表 school
  name, …

  某个不知道啥既有用户又有学校的表
  user_name, school_name, …

• 資深大佬 : knightdf

  没必要加，表名单数形式，字段直接属性名就可以了，不用前缀

• 資深大佬 : raycool

  一这命名真的太差了。

• 資深大佬 : caroline1022

  我个人倾向于当某表在大部分使用场景下都是联合查询的时候，会在前面加前缀，以免有的时候要从 entity 转成 view 返回给前端的时候无法使用统一写好的属性赋值工具而必须手动 set

• 資深大佬 : lazyDaddy

  一笑死了

• 資深大佬 : nobodyknows

  一时间不知道一是不是认真的。

• 資深大佬 : huijiewei

  为什么要加

  要不把数据库名字也加上，跨库查询也是需要的嘛

• 資深大佬 : cp19890714

  user 表
  id
  name

  school 表
  id
  name

  如果这些字段在其他表中使用则 user_id user_name school_id school_name

• 資深大佬 : zxCoder

  @masterclock cod 和 vlu 我是真没见过。。。。

• 資深大佬 : cloudzhou

  @feifanhanmc 这缩写简直莫名其妙，我一向建议，长点就长点，可读性好就可以

• 資深大佬 : strive

  @feifanhanmc 说真的，这命名没眼看

• 資深大佬 : lvdb

  #1L 大亚心了，blk 了

• 資深大佬 : lvdb

  1L 简直也马彳业母瘤啊

• 資深大佬 : young1lin

  1L 在教坏新手，这特么缩写就少了一个字母，你当是 HBase 呢，colunm name 要尽量简短，普通的 RDBMS 就直接用对应的名称就行了。不要写成 school_name，直接写 name 就行了，除非是在中间表，或者其他的表中，作为外键（实际开发不用外键）的存在时候，就要写成 school_name 。尽量见明知意，除非你是用的 HBase 这种，或者其他对字段长度有比较大的优化要求的数据库。

• 資深大佬 : hyqCrystal

  看个人习惯 我喜欢加

• 資深大佬 : noyidoit

  @nekoneko 你这和表情符号似的

• 資深大佬 : seakingii

  我会加.

  我认为表名字段名长一点没关系,直观识别意义比较重要.

• 資深大佬 : towry

  > 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

  一老魔法师了

• 資深大佬 : listenerri

  我也喜欢加

• 資深大佬 : nekoneko

  @noyidoit #95 仔细一看还真是