中文字段名,你为什么不用?

时间:2022-06-03 07:50:03
两年前有个项目,是用.net开发,sqlserver数据库,开发的时候全权委托一位程序员来做,这个程序员很蹩脚,设计和编码方面都比较乱,当时最让人气愤的是他竟然用的是中文字段名,里面充斥着形如"用户ID"、"用户姓名"、"用户年龄"等等,当时让人感觉比较有意思的是所有字段差不多都是四个字解决,大家还戏称四字箴言。出于习惯,大家对于这个程序员的能力产生了怀疑,但是又说不出理由来反驳他,让他不使用中文字段名,而且当时该项目也不是很重要,所以也就随他去,不过因为这个人确实太蹩脚了,所以这个项目做完了CTO就把他给辞了。
    后来,也就是项目开发完一年后,这个项目要改版,公司当作重头项目来做了,这时公司把项目交给另外一个人,这个人一看到中文字段,马上骂骂咧咧,但是也没办法,因为系统本身已经如此了,想改也不可能了(当时公司高层对项目进度逼的很紧,重写是没辙了,而且大家也没想到重构,最重要的是此人很懒),但是后来这个人因为中文字段名的关系对项目熟悉的很快,这个时候我开始对中文字段名不可用的观点有点动摇了。
    现在这个项目又要改版了,公司重新又招了新人过来,因为项目中途小修改不断,已经变的比较复杂了,这个项目已经从个人开发变成了一个由五人组成的开发团队来开发了。但是令人不可思议的是,这个项目组的成员在互相并不认识的情况下竟然在短短的3天内就熟悉了整个项目的需求,偶问他们,他们说用的是中文字段名和表名,所以比较容易理解。这个时候我问了我自己,我们为什么不用中文字段名。

本贴不欢迎接分及顶的,接分和顶的一律不给分

73 个解决方案

#1


现在C#也支持中文变量,但是有几个人用?

#2


用中文字段其实是蛮好的,但是写程序的时候感觉很别扭,查找不是很方便;别人通过数据库更容易篡改东西

#3


我觉得在有些环境下,数据库中文列名会有问题,用英文会稳定的多。拼音都好些

#4


如果一个项目需要从数据库的字段名上去了解需求,只能说明需求说明书做的不够好

#5


如果不考虑多方合作或者不同语言的操作系统的话,当然可以用中文.*的WEBCAST上做演示都是用中文的.个人习惯用英文.也并没觉得有啥不可理解的.对于E文差的当然愿意用中文了.

#6


我没觉得用中文字段名有什么不好!

#7


TO:Tom_Real(如果一个项目需要从数据库的字段名上去了解需求,只能说明需求说明书做的不够好)

一般通过数据库的关系模型图就能够在很大程度上理解需求,那么为什么不去直接看数据库来理解数据库结构,而需要一边边看文档一遍看数据库来理解数据库结构呢?直接看数据库比边看文档边看数据库我感觉应该要快很多吧(当然我不是说文档没用)?现在不是很多人提倡良好结构的代码么?只要代码结构好,易懂,其实有没有注释并不是必须的,对吧?

#8


Tom_Real() drk928(一起看斜阳)说的都有道理,我们应该看到有很多时候项目很赶,特别是修改的时候.

#9


我没觉得用中文字段名有什么不好! 但是用英文会稳定的.

#10


中文不错,但我还是担心..........

#11


我想了想,总结出了几个使用中文字段名的弊端:
第一、代码录入效率比较低,在你输入SQL语句的时候,输入英文的时候又要切换中文输入法,而且中文输入比英文输入麻烦多了,除非你直接用手机来输入(因为在本人的感觉来看,手机里面中文输入比英文输入快,呵呵)。对于这点,现在有现成的ORM系统,再结合IDE的代码提示功能,其实这点大可放心。
第二、也就是上面的Tom_Real兄和Drk928兄所说,用中文可能导致系统不稳定。对于SQL2000来说,中文支持已经很稳定了。
第三、其实和第二点有点相似,使用中文的话比较难以跨平台,因为虽然微软的东西对于中文支持的比较好,但是到了Linux等系统下面,中文支持一直是他们的诟病。而且现在很多诸如MySQL等数据库对于中文的数据库内容支持的都不是很好。

#12


VS2005的数据集对中文支持不好,用中文字段名会出错。

#13


我认为最理想的状态是:
不需要看数据库,直接看需求说明书,就可以全部了解系统的功能需要。数据库只是为了实现功能需求和更好的达到效率而设计的。
就是说,数据库设计已经属于设计阶段,而设计阶段是在需求调查分析完成后的阶段,如果从设计阶段的东西上去了解前一阶段的东西,本身就是逻辑问题。

#14


其实,是开发文档,维护文档没做好。

#15


to czhenq(原来是心累了):
可以用中文做变量名吗?我没试成功啊。

#16


欢迎大家讨论,指教

#17


Tom_Real():我认为最理想的状态是:
不需要看数据库,直接看需求说明书,就可以全部了解系统的功能需要。数据库只是为了实现功能需求和更好的达到效率而设计的。
就是说,数据库设计已经属于设计阶段,而设计阶段是在需求调查分析完成后的阶段,如果从设计阶段的东西上去了解前一阶段的东西,本身就是逻辑问题。
-------------------
如果是进行项目的修改呢?抑或是进行项目的重新开发呢?在这个时候已经有现成的系统可以参照,为什么还要劳心劳力的去重新获取一遍系统原来做好的需求?需求文档固然重要,但是一个成型的系统比任何文档都有用,至少在我看来是酱紫的。
一点浅见,期望大家多多指教
 

#18


其实,什么事情都是有利有弊。
用中文名容易上手,但是如果跨平台,多语言,多项目交叉在一起的话,是有更多的弊端的。
用中文,还没见过用得非常好的,如果也能搞的很规范,那也不错。在单一平台上开发单一应用时,的确可以尝试。

#19


英文单词的唯一性比中文要好,事实上很多时候英文比中文更容易理解。

可以为数据库的字段加上中文描述。

同一个英文单词可以对应很多个中文词汇,而反过来却不是,在程序员都习惯了英文的环境的时候,中文反而会带来困扰。

#20


还有很多时候是数据库建模没搞好,导致数据库变得异常复杂。一个好的数据库设计、一段好的代码,都应该是自我描述的……。

#21


同意楼上的见解
但是如果有一些程序员英文不好的呢?(不要告诉我没有,我碰到过很多),是直接看字段比较明了还是边看字段边看注释呢?我一般都用SqlServer的关系图来理解数据库结构,当表多到一定程度的时候我只让他显示字段名来查看,因为酱紫方便,而且关系图比较容易从大局上理解整个系统

#22


我就用中文字段

#23


我暂时也不觉得这样用会有什么问题
可能是一种习惯吧  总觉得有点不伦不类

#24


估计什么时候有国人自己的操作系统和自己设计的数据库就很爽的用了,select 用“查询”,from 用“从”,哈哈,那个爽啊

#25


英文还是中文都是习惯问题,无所谓的。随后无非担心数据库部署时候编码环境会不会出问题,所以只要不涉及Globalize,中文字段也能考虑。

#26


用中文跨平台、地域性、语言性,多语言版本,这样做不太好解决吧,况且数据库的编码如果不一样的话,会不会出现不可预料的问题

#27


想想吧,如果中文可以这么大胆的使用..大公司为什么不使用呢?说到项目进度要求,大公司何尝不比小公司更加注重呢??

你考虑过使用NHibernate后,你的中文字段会存在问题吗???

你考虑过移植性吗??你的项目从一个不被重视的项目,到开发为完整的项目,再到重点项目..难道你能保证它以后就不升级吗??

做项目,最麻烦的是维护和升级..使用中文或许在现在觉得很不错..但是以后呢??多想想就知道了

#28


在1.1版就有中文字段名的支持了甚至方法都可以
但是做项目不能只为维护,如果项目不大的改动用中文字段名可以
但是如果进行大的改动比如框架等,反而回暴漏很多问题,
在说用中文字段名字的话写代码的时候来回切换输入法也不方便
项目维护有好的文档和代码的可性,良好的编码规范才是重要的并不怎么赞成中文字段名

#29


我想是因为还有很多数据库/软件不支持Unicode

如果以后要移植到那些数据库或平台下,就会有问题

如果光是目前.NET/ASP MSSQL,并且是中文用户,

那么是可以提倡使用中文了

而大公司因为要考虑开发的软件用户应用环境可能是其它非中文环境

并且维护人员也有可能来自世界各地,在中文没有成为世界语的情况下

自然不能用中文了。

相信中文会越来越流行,未来是属于中国的 :)

#30


至于 ivony 说的什么

"英文单词的唯一性比中文要好,事实上很多时候英文比中文更容易理解。"

根本是瞎扯,那是你自己已经有了一些英文基础了(或者说已经非常流利了)

甚至已经把中文都快忘得差不多了

#31


中文在项目里好用,我想重要的一点是这个数据库没有相应的文档,其实文档并不能做,用现成的工具,比如powerdesigner,这样既可以显示中文的数据结构,而实际的表字段还是英文

#32


支持说国语,支持写英语

#33


如果是UTF8的会有问题(三个字节),恩,如果不想有什么不必要的麻烦,请用单字节的来命名。

#34


问挑刺几个简单的英文单词的翻译:
Name是名称还是姓名?
Account是帐号还是账号?
Pricipal是什么?
Identity是什么?
Category和Type分别用什么?

#35


to Ivony , 

首先,我英文很烂,所以请不要考我英文,呵呵

另外,你这例子不正说明了 中文要比英文表述得准确么?

#36


使用中文没问题的

#37


To Ivony()
每种语言在语法上都有自己的优势,在这个上面永远也讨论不完。

例如,如果让你翻译calling这个词,你觉得是翻译成职业, 行业, 邀请, 点名, 召集中的哪个比较好呢?

但是中文里面的职业就是职业,至少不会出现第二个解释

就像你说的Name,到底是翻译成名称还是姓名好呢?而如果用中文的话,姓名就是姓名,名称就是名称,毫无二义性。

因为我们的母语是中文,所以我们无论在什么时候第一反应就是中文的意思,而非其英文意思

#38


我们以前做的项目,数据库中的表名和字段名都有用中文的,没发现什么问题

#39


中文字段在数据库移植的时候比较麻烦,如果都在windows平台也还好说,涉及到unix上就麻烦了

#40


我觉得现在不是讨论中文和英文哪个更好的问题,而是在讨论数据库字段是用中文字段还是英文字段的问题。
如果是表述一个思想、内容(比如写小说),中文和英文都是很好的,毕竟名著中的中国名著和英文名著都很多,柬埔寨话的名著就很少,说明在表述方面,中文和英文都是很好的方式,有丰富的表述方法。
可是在计算机语言中,中文远不如英文了。我想,计算机语言中的中文最终都会解释成英文字符,并最终成为01之类的东西。
很简单的例子,从程序的通用性、健壮性、可移植性考虑,英文更优。
一个中文字段的数据库,在美国使用,是否需要同时安装一个中文输入法,才能用"select 用户名 from 用户表"呢?有点多此一举。

#41


用中文字段對于數據庫的維護,以及資料抓取比較難處理,
SELECT 用戶ID FROM 用戶表,有點亂。
但是TABLE容易理解.
其實也可以在TABLE中增加備注呀.也可解決難理解的問題.

#42


使用中文名感觉打起字来有点麻烦。
中英文切换来去。很麻烦

#43


我不是很同意楼主的观点,英文表达清楚了,同样很好理解
何况中文的字段名,可能存在一些未可知的隐患,总之让人觉得不够踏实吧

#44


虽然我英文很烂,但也没想过用中文,总觉得不习惯
看来以后应该要用中文字段了

#45


我并不是说使用中文很好
因为我也不大赞同用中文
但是我又找不到为什么不能使用中文
我一直在反驳自己
但是又找不到很好的理由
所以想到这里来讨论讨论
为什么不能使用中文

希望大家能够继续讨论,让大家都找到令自己满意的答案

#46


我不用开始是因为写起来慢

后来是因为接手的项目已经有了现成的表

再后来是因为老板不认识中文不许我们写

所以一直没有机会用它,呵呵

#47


現在的數據庫全都使用unicode碼了,如果中文會出問題那你用英文同樣也會出問題,不是水平極極高高的超級高手,是不可能用gb碼建立出數據庫表名或字段名的。

就如你用xp,只要全選後按了復制,復制後的內容不管是什麼內碼都會自動變成unicode碼的原理一樣!

#48


只有Sql Server2000和.NET对中文的支持较好
MySql,Oracle都不行

#49


虽然说中文字段好理解,但是要是有改数据库可能就会有问题,
我本人还是建议,用英文字段名好

#50


我用中文字段名开发了多个系统;
进销存
生产管理(计件\计时\生产跟踪)
财务
(系统中包括:视图\存储过程\表\变量都用中文).
暂时没有发现因此引起任何问题.

#1


现在C#也支持中文变量,但是有几个人用?

#2


用中文字段其实是蛮好的,但是写程序的时候感觉很别扭,查找不是很方便;别人通过数据库更容易篡改东西

#3


我觉得在有些环境下,数据库中文列名会有问题,用英文会稳定的多。拼音都好些

#4


如果一个项目需要从数据库的字段名上去了解需求,只能说明需求说明书做的不够好

#5


如果不考虑多方合作或者不同语言的操作系统的话,当然可以用中文.*的WEBCAST上做演示都是用中文的.个人习惯用英文.也并没觉得有啥不可理解的.对于E文差的当然愿意用中文了.

#6


我没觉得用中文字段名有什么不好!

#7


TO:Tom_Real(如果一个项目需要从数据库的字段名上去了解需求,只能说明需求说明书做的不够好)

一般通过数据库的关系模型图就能够在很大程度上理解需求,那么为什么不去直接看数据库来理解数据库结构,而需要一边边看文档一遍看数据库来理解数据库结构呢?直接看数据库比边看文档边看数据库我感觉应该要快很多吧(当然我不是说文档没用)?现在不是很多人提倡良好结构的代码么?只要代码结构好,易懂,其实有没有注释并不是必须的,对吧?

#8


Tom_Real() drk928(一起看斜阳)说的都有道理,我们应该看到有很多时候项目很赶,特别是修改的时候.

#9


我没觉得用中文字段名有什么不好! 但是用英文会稳定的.

#10


中文不错,但我还是担心..........

#11


我想了想,总结出了几个使用中文字段名的弊端:
第一、代码录入效率比较低,在你输入SQL语句的时候,输入英文的时候又要切换中文输入法,而且中文输入比英文输入麻烦多了,除非你直接用手机来输入(因为在本人的感觉来看,手机里面中文输入比英文输入快,呵呵)。对于这点,现在有现成的ORM系统,再结合IDE的代码提示功能,其实这点大可放心。
第二、也就是上面的Tom_Real兄和Drk928兄所说,用中文可能导致系统不稳定。对于SQL2000来说,中文支持已经很稳定了。
第三、其实和第二点有点相似,使用中文的话比较难以跨平台,因为虽然微软的东西对于中文支持的比较好,但是到了Linux等系统下面,中文支持一直是他们的诟病。而且现在很多诸如MySQL等数据库对于中文的数据库内容支持的都不是很好。

#12


VS2005的数据集对中文支持不好,用中文字段名会出错。

#13


我认为最理想的状态是:
不需要看数据库,直接看需求说明书,就可以全部了解系统的功能需要。数据库只是为了实现功能需求和更好的达到效率而设计的。
就是说,数据库设计已经属于设计阶段,而设计阶段是在需求调查分析完成后的阶段,如果从设计阶段的东西上去了解前一阶段的东西,本身就是逻辑问题。

#14


其实,是开发文档,维护文档没做好。

#15


to czhenq(原来是心累了):
可以用中文做变量名吗?我没试成功啊。

#16


欢迎大家讨论,指教

#17


Tom_Real():我认为最理想的状态是:
不需要看数据库,直接看需求说明书,就可以全部了解系统的功能需要。数据库只是为了实现功能需求和更好的达到效率而设计的。
就是说,数据库设计已经属于设计阶段,而设计阶段是在需求调查分析完成后的阶段,如果从设计阶段的东西上去了解前一阶段的东西,本身就是逻辑问题。
-------------------
如果是进行项目的修改呢?抑或是进行项目的重新开发呢?在这个时候已经有现成的系统可以参照,为什么还要劳心劳力的去重新获取一遍系统原来做好的需求?需求文档固然重要,但是一个成型的系统比任何文档都有用,至少在我看来是酱紫的。
一点浅见,期望大家多多指教
 

#18


其实,什么事情都是有利有弊。
用中文名容易上手,但是如果跨平台,多语言,多项目交叉在一起的话,是有更多的弊端的。
用中文,还没见过用得非常好的,如果也能搞的很规范,那也不错。在单一平台上开发单一应用时,的确可以尝试。

#19


英文单词的唯一性比中文要好,事实上很多时候英文比中文更容易理解。

可以为数据库的字段加上中文描述。

同一个英文单词可以对应很多个中文词汇,而反过来却不是,在程序员都习惯了英文的环境的时候,中文反而会带来困扰。

#20


还有很多时候是数据库建模没搞好,导致数据库变得异常复杂。一个好的数据库设计、一段好的代码,都应该是自我描述的……。

#21


同意楼上的见解
但是如果有一些程序员英文不好的呢?(不要告诉我没有,我碰到过很多),是直接看字段比较明了还是边看字段边看注释呢?我一般都用SqlServer的关系图来理解数据库结构,当表多到一定程度的时候我只让他显示字段名来查看,因为酱紫方便,而且关系图比较容易从大局上理解整个系统

#22


我就用中文字段

#23


我暂时也不觉得这样用会有什么问题
可能是一种习惯吧  总觉得有点不伦不类

#24


估计什么时候有国人自己的操作系统和自己设计的数据库就很爽的用了,select 用“查询”,from 用“从”,哈哈,那个爽啊

#25


英文还是中文都是习惯问题,无所谓的。随后无非担心数据库部署时候编码环境会不会出问题,所以只要不涉及Globalize,中文字段也能考虑。

#26


用中文跨平台、地域性、语言性,多语言版本,这样做不太好解决吧,况且数据库的编码如果不一样的话,会不会出现不可预料的问题

#27


想想吧,如果中文可以这么大胆的使用..大公司为什么不使用呢?说到项目进度要求,大公司何尝不比小公司更加注重呢??

你考虑过使用NHibernate后,你的中文字段会存在问题吗???

你考虑过移植性吗??你的项目从一个不被重视的项目,到开发为完整的项目,再到重点项目..难道你能保证它以后就不升级吗??

做项目,最麻烦的是维护和升级..使用中文或许在现在觉得很不错..但是以后呢??多想想就知道了

#28


在1.1版就有中文字段名的支持了甚至方法都可以
但是做项目不能只为维护,如果项目不大的改动用中文字段名可以
但是如果进行大的改动比如框架等,反而回暴漏很多问题,
在说用中文字段名字的话写代码的时候来回切换输入法也不方便
项目维护有好的文档和代码的可性,良好的编码规范才是重要的并不怎么赞成中文字段名

#29


我想是因为还有很多数据库/软件不支持Unicode

如果以后要移植到那些数据库或平台下,就会有问题

如果光是目前.NET/ASP MSSQL,并且是中文用户,

那么是可以提倡使用中文了

而大公司因为要考虑开发的软件用户应用环境可能是其它非中文环境

并且维护人员也有可能来自世界各地,在中文没有成为世界语的情况下

自然不能用中文了。

相信中文会越来越流行,未来是属于中国的 :)

#30


至于 ivony 说的什么

"英文单词的唯一性比中文要好,事实上很多时候英文比中文更容易理解。"

根本是瞎扯,那是你自己已经有了一些英文基础了(或者说已经非常流利了)

甚至已经把中文都快忘得差不多了

#31


中文在项目里好用,我想重要的一点是这个数据库没有相应的文档,其实文档并不能做,用现成的工具,比如powerdesigner,这样既可以显示中文的数据结构,而实际的表字段还是英文

#32


支持说国语,支持写英语

#33


如果是UTF8的会有问题(三个字节),恩,如果不想有什么不必要的麻烦,请用单字节的来命名。

#34


问挑刺几个简单的英文单词的翻译:
Name是名称还是姓名?
Account是帐号还是账号?
Pricipal是什么?
Identity是什么?
Category和Type分别用什么?

#35


to Ivony , 

首先,我英文很烂,所以请不要考我英文,呵呵

另外,你这例子不正说明了 中文要比英文表述得准确么?

#36


使用中文没问题的

#37


To Ivony()
每种语言在语法上都有自己的优势,在这个上面永远也讨论不完。

例如,如果让你翻译calling这个词,你觉得是翻译成职业, 行业, 邀请, 点名, 召集中的哪个比较好呢?

但是中文里面的职业就是职业,至少不会出现第二个解释

就像你说的Name,到底是翻译成名称还是姓名好呢?而如果用中文的话,姓名就是姓名,名称就是名称,毫无二义性。

因为我们的母语是中文,所以我们无论在什么时候第一反应就是中文的意思,而非其英文意思

#38


我们以前做的项目,数据库中的表名和字段名都有用中文的,没发现什么问题

#39


中文字段在数据库移植的时候比较麻烦,如果都在windows平台也还好说,涉及到unix上就麻烦了

#40


我觉得现在不是讨论中文和英文哪个更好的问题,而是在讨论数据库字段是用中文字段还是英文字段的问题。
如果是表述一个思想、内容(比如写小说),中文和英文都是很好的,毕竟名著中的中国名著和英文名著都很多,柬埔寨话的名著就很少,说明在表述方面,中文和英文都是很好的方式,有丰富的表述方法。
可是在计算机语言中,中文远不如英文了。我想,计算机语言中的中文最终都会解释成英文字符,并最终成为01之类的东西。
很简单的例子,从程序的通用性、健壮性、可移植性考虑,英文更优。
一个中文字段的数据库,在美国使用,是否需要同时安装一个中文输入法,才能用"select 用户名 from 用户表"呢?有点多此一举。

#41


用中文字段對于數據庫的維護,以及資料抓取比較難處理,
SELECT 用戶ID FROM 用戶表,有點亂。
但是TABLE容易理解.
其實也可以在TABLE中增加備注呀.也可解決難理解的問題.

#42


使用中文名感觉打起字来有点麻烦。
中英文切换来去。很麻烦

#43


我不是很同意楼主的观点,英文表达清楚了,同样很好理解
何况中文的字段名,可能存在一些未可知的隐患,总之让人觉得不够踏实吧

#44


虽然我英文很烂,但也没想过用中文,总觉得不习惯
看来以后应该要用中文字段了

#45


我并不是说使用中文很好
因为我也不大赞同用中文
但是我又找不到为什么不能使用中文
我一直在反驳自己
但是又找不到很好的理由
所以想到这里来讨论讨论
为什么不能使用中文

希望大家能够继续讨论,让大家都找到令自己满意的答案

#46


我不用开始是因为写起来慢

后来是因为接手的项目已经有了现成的表

再后来是因为老板不认识中文不许我们写

所以一直没有机会用它,呵呵

#47


現在的數據庫全都使用unicode碼了,如果中文會出問題那你用英文同樣也會出問題,不是水平極極高高的超級高手,是不可能用gb碼建立出數據庫表名或字段名的。

就如你用xp,只要全選後按了復制,復制後的內容不管是什麼內碼都會自動變成unicode碼的原理一樣!

#48


只有Sql Server2000和.NET对中文的支持较好
MySql,Oracle都不行

#49


虽然说中文字段好理解,但是要是有改数据库可能就会有问题,
我本人还是建议,用英文字段名好

#50


我用中文字段名开发了多个系统;
进销存
生产管理(计件\计时\生产跟踪)
财务
(系统中包括:视图\存储过程\表\变量都用中文).
暂时没有发现因此引起任何问题.