数据库表设计是否需要在字段前标注字段的所属对象，比如用户表的名字是 user_name,学校表的名字字段是 school_name
Renco · 2021-04-14 22:06:57 +08:00 · 8110 次点击这是一个创建于 1329 天前的主题，其中的信息可能已经有所发展或是发生改变。
这样写法会不会过于冗余。
 |
1
feifanhanmc 2021-04-14 22:09:13 +08:00 via iPhone
目前在用的一套感觉比较好的命名规范
nam_school nam_user cod_sex vlu_mail num_phone |
 |
2
dethan 2021-04-14 22:09:31 +08:00 via Android
写也行，不写也行。没人说不好，也没人说好。
|
 |
4
zoharSoul 2021-04-14 22:30:30 +08:00  2
@feifanhanmc 这都啥奇奇怪怪的缩写
|
 |
5
David1119 2021-04-14 22:34:03 +08:00 45
@feifanhanmc 哪来的自信觉得好？少写一个字母是什么鬼？？？
|
|
6
feifanhanmc 2021-04-14 23:08:55 +08:00 via iPhone
@David1119 这叫奇怪的缩写？麻瓜
|
 |
7
liprais 2021-04-14 23:26:39 +08:00 via iPhone
表名不是干这个用的么
|
 |
8
oott123 2021-04-14 23:35:45 +08:00
@feifanhanmc 关于 1 楼提到的缩写，nam 应该是 name，num 是 number，这都没问题。可是 cod 和 vlu 分别是什么的缩写呢？我想了很久都没想出来，能否指点一下。
|
 |
10
SuperMild 2021-04-14 23:39:51 +08:00 1
|
 |
11
GuoGuang 2021-04-14 23:56:30 +08:00 4
@feifanhanmc 你这漏几个字母我觉得比拼音都离谱，lear_record 、ou_log
|
 |
12
zidian 2021-04-15 00:07:53 +08:00 via iPhone
从来不加。
而且很迷的一件事，好像只有 id code name 爱加上表名，其他比如 age sex 就从没见过人加。 |
 |
13
Chieh 2021-04-15 00:09:17 +08:00
@feifanhanmc 为了“简化”英文少了拼写，导致懂英文的和不懂英文的都看不懂
|
 |
14
c6h6benzene 2021-04-15 00:15:25 +08:00 1
|
 |
15
ipwx 2021-04-15 00:21:45 +08:00
@c6h6benzene u.name 不就隐含 user.name 么，根据上下文都能知道。再不济到时候用 user.name 它不香嘛。。。
等等，除非你为了取出来到 php 里面的时候可以 select * ... |
|
16
c6h6benzene 2021-04-15 00:53:57 +08:00
@ipwx #15 这不就是为了防止 user 和 unit 这种都是 U 开头的😂SQL JOIN 多的时候，ID 前面不加前缀我都想骂人
|
 |
17
baobao1270 2021-04-15 02:04:15 +08:00 via Android
不加
反正 ORM 帮我搞定，现在几乎不怎么写 sql 了 |
 |
18
neoblackcap 2021-04-15 04:00:44 +08:00
如果你用的是关系型数据库，那么你这个做法就是反模式。毕竟关系型数据库讲究数据模型正交。
|
 |
19
stabc 2021-04-15 04:04:38 +08:00
我倾向于不加前缀
|
 |
20
kchum 2021-04-15 07:01:14 +08:00
不加. 连表有也有表名在前面, 用 Alias 出错也只能怪自己
|
 |
21
morimi2026 2021-04-15 07:07:14 +08:00 via iPhone 30
@feifanhanmc 这是我见过的最差的命名规范
|
 |
22
ColouredGlaze 2021-04-15 07:21:40 +08:00
name 是 mysql 数据库的保留字，个人建议是数据库字段加上前缀，代码实体去掉前缀，映射做好，个人建议
|
 |
23
raaaaaar 2021-04-15 07:41:43 +08:00 via Android
id 你们也加吗？但是 gorm 这种框架会自动加一个 id 字段，需要额外弄么。。
|
 |
24
iseki 2021-04-15 07:57:02 +08:00 via Android
不用
|
 |
25
VeryZero 2021-04-15 08:33:51 +08:00
个人不喜欢加，但是公司要求加。。
因为很多表名本身就自带前缀，字段名再加表名前缀，这是在套娃吗。字段名冲突用别名解决不香吗。 另外坚决反对缩写的，少一两个字符又不会影响数据库性能，是想让别人觉得你很厉害吗？ 程序里面也是同理，有些人就喜欢整各种稀奇古怪的缩写变量名，方法名。生怕别人不知道这坨屎是谁拉的。 |
 |
26
masterclock 2021-04-15 08:36:46 +08:00 4
@feifanhanmc 这是我见过的最差的命名规范
|
 |
27
sutra 2021-04-15 08:40:14 +08:00
如果字段名都需要用表名做前缀，那还需要表干什么？
|
 |
28
statement 2021-04-15 08:40:20 +08:00
原表不加 但关联表肯定要加 不然同一张表不两个 id 和 name
|
 |
29
encro 2021-04-15 08:41:35 +08:00
表名就可以表示自身了，所以没必要加前缀，除非外键 order.user_id 这样的
|
 |
30
siweipancc 2021-04-15 08:55:34 +08:00 via iPhone
挺可怕的，一言不合就骂人:D
|
 |
31
TimPeake 2021-04-15 08:57:12 +08:00
😂
|
 |
32
xuanbg 2021-04-15 08:57:34 +08:00
不加，我手写 sql 也不加。
|
 |
33
rationa1cuzz 2021-04-15 09:04:34 +08:00
考虑到 join 的情况我是都是用 xx_name，其实可以起别名，但是某些情况下不好写(狗头)
|
 |
34
IvanLi127 2021-04-15 09:06:37 +08:00 via Android
完全没必要，因为库里这冗余的命名，前后端业务、接口、界面都得多写这些。表加这个是不会用 sql 的 alias 么？不写不会影响产出质量
|
 |
35
wangritian 2021-04-15 09:34:54 +08:00
我觉得没必要带，同理包括 api 接口设计
|
 |
36
PerFectTime 2021-04-15 09:37:09 +08:00
外键才会加上描述
对应实体中的属性不加 |
 |
37
passerbytiny 2021-04-15 10:02:27 +08:00 via Android 2
（古老的，或者大型的）数据库设计体系， “列”是直属于数据库，而不是先属于“表”再间接属于数据库的，这样列名必须要能自举。在以前那种到处是“review”，甚至用存储过程代替应用编程的时候，这种从全局层面管理列的架构，应该是有好处的。
后来因为 ORM，或者是回归原始的关系数据模型，列（属性 /字段），只能从属于表（实体 /类）了，列名是否能自举，就不再重要了。 然而以上那些只是副因，如何命名，主要还是取决于开发人 /团队的自制规范。 |
 |
38
clf 2021-04-15 10:04:18 +08:00
加前缀的好处就是避免有些运维直接手写 sql 时忘了加反引号，比如 name 是 sql 的关键字，一些情况下不加反引号就会报错。当然咯，如果全部操作都是在 IDE 和 ORM 框架下操作的，不需要手写 SQL，就没这个问题。
不过一般情况下，外部数据才会加前缀，本体属性不会加前缀。 |
 |
39
Outshine 2021-04-15 10:06:43 +08:00 1
找不到这样写的必要，join 的时候 table.name 不就行了？
---- 我们这边的习惯就是只有外键会加表名，比如文章表的作者 ID 和分类 ID：creator_id 、category_id --- 另外，#1 @feifanhanmc 的那个命名规范简直烂透了 |
 |
40
cheng6563 2021-04-15 10:14:29 +08:00
我司是如
SCHL_NAME SCHL_ADDR SCHL_CICO SCHL_CINA |
 |
41
chendy 2021-04-15 10:16:07 +08:00
不加，加了之后反而要写成 school.school_name 就很麻烦
|
 |
42
angeloce 2021-04-15 10:19:01 +08:00
像 id 这种代表数据的唯一主键，考虑到数据流转时各方的理解，是应该加上前缀的而且是全局唯一前缀。 命名常见的字段，如果能考虑到流转时关联表合并、数据层级被打平，也应该加上。
|
 |
43
jucelin 2021-04-15 10:35:39 +08:00
|
 |
44
barbery 2021-04-15 10:41:28 +08:00
这样写法会不会过于冗余。
===== 不会 |
 |
45
l00t 2021-04-15 10:47:37 +08:00
加。
|
 |
46
kkkkkrua 2021-04-15 10:50:15 +08:00
加不加都可，但是碰到明明是数据库的关键字，就得加上了，比如 type
|
 |
47
frankfang1995 2021-04-15 10:57:20 +08:00 1
@feifanhanmc 性别能不能别用 sex，gender 懂不懂？
|
 |
48
dayudayupao 2021-04-15 11:00:58 +08:00 1
@feifanhanmc 你这个是真看不懂,你确定是比较好的命名规范? 就你自己看的懂吧
|
 |
49
aitaii 2021-04-15 11:02:39 +08:00 3
目前在用的一套感觉比较好的命名规范
n_sol n_ur cd_sx vu_ail nu_pne |
|
50
dayudayupao 2021-04-15 11:04:10 +08:00 2
@feifanhanmc 看了这么多评论都是喷你的就舒服了,你这些典型的自己菜还嘴臭
|
|
51
dayudayupao 2021-04-15 11:04:56 +08:00
@aitaii 好的,马上拿去用
|
 |
52
limuyan44 2021-04-15 11:05:10 +08:00
school.schoolname 会不会很奇怪。
|
 |
53
romisanic 2021-04-15 11:06:33 +08:00
当前对象表里如果用到了关联其他对象的一些字段，就加上对象名
比如学生表里要加班级 ID，那就叫 class_id，但是学生自己的 ID 就叫 id 同样反过来，如果课程对象要用到学生的 ID 的时候，也应该叫 student_id |
|
54
dayudayupao 2021-04-15 11:09:12 +08:00
我个人觉得是不加好, 已经有表名区分了
|
 |
55
lzj307077687 2021-04-15 11:25:06 +08:00
我不加 复制粘贴可以少改几行
|
 |
56
chenmobuys 2021-04-15 11:28:27 +08:00
尽量别用数据库保留字段，加好备注，随你怎么取名
|
 |
57
nekoneko 2021-04-15 11:54:44 +08:00 3
向一楼学习,目前没用以后也不会用的一套感觉比较好的命名规范
n_s n_u c_s v_a n_p 个人不习惯 user_name 这样的命名方式 user 表已经说明问题了 |
|
59
feifanhanmc 2021-04-15 12:10:56 +08:00 via iPhone
@frankfang1995 #46 笑了这也能杠
|
|
60
feifanhanmc 2021-04-15 12:13:07 +08:00 via iPhone
@dayudayupao #49 呦，来这里找优越感啦
|
 |
61
AlexWIT 2021-04-15 12:33:59 +08:00 6
@feifanhanmc 笑拉了，没十年脑血栓想不出来这缩写
|
 |
62
no1xsyzy 2021-04-15 12:35:10 +08:00
@feifanhanmc 匈牙利命名法复刻，没想到这里还能看到不识好歹的
|
 |
63
WilliamYang 2021-04-15 12:58:27 +08:00 via iPhone
代码整洁之道，多看看书，你就会有答案了
|
|
64
morimi2026 2021-04-15 13:01:51 +08:00
@feifanhanmc 命名要避免非通用的缩写，这样才有可读性。可读性高就维护起来就容易。
|
 |
65
star7th 2021-04-15 13:53:50 +08:00
建议写，方便一眼看出这是什么字段。
|
 |
66
Rwing 2021-04-15 13:57:23 +08:00 1
不加，另外一楼真的笑到我了
|
 |
67
ychost 2021-04-15 14:00:52 +08:00
不加，join 的时候 as 一下就好了
|
 |
68
deepmindlab 2021-04-15 14:04:26 +08:00 1
@feifanhanmc 这命名规范比我今天的粑粑还臭
|
 |
69
newtype0092 2021-04-15 14:09:06 +08:00 1
@feifanhanmc V2 点赞功能太不人性化了，自己的点赞有提醒，别人喷自己的点赞却没有，这样想一个一个喷回去太麻烦了，咱们一起给站长提建议加上这个功能吧🐶
|
 |
70
tairan2006 2021-04-15 14:09:42 +08:00
不用加，不过如果是为了避免数据库的保留字，可以加前缀
|
 |
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 （获取商品评论） |
 |
72
caixiaomao 2021-04-15 14:13:33 +08:00
没必要 一般表名会体现 但是在关联表之类的会加上
|
 |
73
CantSee 2021-04-15 14:17:46 +08:00
我们一般都是固定的:比如活动表.是一个固定前缀加英文 XXX_ACTIVE_BASE, 如果是活动条件表就是 XXX_ACTIVE_LIMIT
|
 |
74
wupher 2021-04-15 14:54:08 +08:00
一般不需要。
除非你进行的是超大型项目，类似运营商 CRM 这类。表结构大，数据多，未来会上 N 多个 BI 、分析系统，主表如用户或者交易还经常会被各种联表、过程进行查询。上述情况，推荐添加。实际上，电信以及相应厂商的规范里面也写的很清楚。 正常一般应用，我是觉得 User.name 比 user.userName 好多了。 |
 |
75
lvtuyukuai 2021-04-15 15:26:58 +08:00 1
1 楼赶紧回 M78 星云吧，地球已经没有怪兽了。
|
 |
76
way2create 2021-04-15 15:37:27 +08:00
个人不喜欢加 特别是 id
|
|
77
ipwx 2021-04-15 15:41:22 +08:00
@c6h6benzene 如果只是 join，那么别名用 unit & user 不就行了。。。
|
|
78
dayudayupao 2021-04-15 15:49:49 +08:00
一楼要是不骂人麻瓜,我觉得作为一种讨论倒也没什么,都是互相学习过来的,关键是自己滂臭的命名别人反驳一下都不行....
|
 |
79
id4alex 2021-04-15 15:51:27 +08:00
好处是以你眼就可以看出来这个字段是来自哪个表, 坏处是太啰嗦.
大家一起权衡 |
 |
80
lithiumii 2021-04-15 16:02:55 +08:00
用户表 user
name, school_name, ... 学校表 school name, ... 某个不知道啥既有用户又有学校的表 user_name, school_name, ... |
 |
81
knightdf 2021-04-15 16:16:29 +08:00
没必要加，表名单数形式，字段直接属性名就可以了，不用前缀
|
 |
82
raycool 2021-04-15 17:01:35 +08:00
一楼这命名真的太差了。
|
 |
83
caroline1022 2021-04-15 17:12:52 +08:00
我个人倾向于当某表在大部分使用场景下都是联合查询的时候，会在前面加前缀，以免有的时候要从 entity 转成 view 返回给前端的时候无法使用统一写好的属性赋值工具而必须手动 set
|
 |
84
lazyDaddy 2021-04-15 17:25:03 +08:00 1
一楼笑死了
|
 |
85
nobodyknows 2021-04-15 18:42:36 +08:00
一时间不知道一楼是不是认真的。
|
 |
86
huijiewei 2021-04-15 19:00:06 +08:00
为什么要加
要不把数据库名字也加上，跨库查询也是需要的嘛 |
 |
87
cp19890714 2021-04-15 19:02:14 +08:00
user 表
id name school 表 id name 如果这些字段在其他表中使用则 user_id user_name school_id school_name |
 |
88
zxCoder 2021-04-15 19:05:41 +08:00
@masterclock cod 和 vlu 我是真没见过。。。。
|
 |
89
cloudzhou 2021-04-15 19:32:46 +08:00 1
@feifanhanmc 这缩写简直莫名其妙，我一向建议，长点就长点，可读性好就可以
|
 |
90
strive 2021-04-15 19:50:24 +08:00 1
@feifanhanmc 说真的，这命名没眼看
|
 |
91
mx8Y3o5w3M70LC4y 2021-04-15 20:42:37 +08:00 via Android 1
#1L 大亚心了，blk 了
|
|
92
mx8Y3o5w3M70LC4y 2021-04-15 20:46:02 +08:00 via Android 1
1L 简直也马彳业母瘤啊
|
 |
93
young1lin 2021-04-15 20:53:00 +08:00 1
1L 在教坏新手，这特么缩写就少了一个字母，你当是 HBase 呢，colunm name 要尽量简短，普通的 RDBMS 就直接用对应的名称就行了。不要写成 school_name，直接写 name 就行了，除非是在中间表，或者其他的表中，作为外键（实际开发不用外键）的存在时候，就要写成 school_name 。尽量见明知意，除非你是用的 HBase 这种，或者其他对字段长度有比较大的优化要求的数据库。
|
 |
94
hyqCrystal 2021-04-15 21:07:23 +08:00
看个人习惯 我喜欢加
|
 |
96
seakingii 2021-04-15 22:36:47 +08:00
我会加.
我认为表名字段名长一点没关系,直观识别意义比较重要. |
 |
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 那样的人 |
 |
98
codingadog 2021-04-15 22:52:57 +08:00 via Android
一楼老魔法师了🤣
|
 |
99
listenerri 2021-04-16 09:00:34 +08:00
我也喜欢加
|
Select Language