L
linbz
Unregistered / Unconfirmed
GUEST, unregistred user!
请问在MSSQL2000和Oracle,建表数据表字段有汉字好还是字母好,请说明一下区别.谢谢!
L
lw86
Unregistered / Unconfirmed
GUEST, unregistred user!
当然是用字母好，否则编起程来你会想哭的，而且程序这个东西的确还是英语好一些。
实际上，你用汉字字段无非是想将来维护上方便一些或编程时直接显示字段名为汉字，
但这些实现起来都不难，SQL2000在企业管理器的建表中支持备注。而要在程序中显示
字段的汉字名可在select语名中用as。
实际上，你用汉字字段无非是想将来维护上方便一些或编程时直接显示字段名为汉字，
但这些实现起来都不难，SQL2000在企业管理器的建表中支持备注。而要在程序中显示
字段的汉字名可在select语名中用as。
H
HunterTeam
Unregistered / Unconfirmed
GUEST, unregistred user!
当然是用字母好，且不说楼上说的哪些，开发时在英文与汉字间切换来切换去就够你烦的了。
X
xf-wangyi
Unregistered / Unconfirmed
GUEST, unregistred user!
不会吧，你想用汉字？？？
那会死人的[
]
还是起个有意义的名字要好，加上前缀和后缀
那会死人的[
]还是起个有意义的名字要好，加上前缀和后缀
W
whitehorse
Unregistered / Unconfirmed
GUEST, unregistred user!
sql2000使用汉字字段也可以。
T
tseug
Unregistered / Unconfirmed
GUEST, unregistred user!
我支持使用汉字，主要是这样可使用户能够自己维护数据库数据。通常，如果不允许
用户自己维护数据库，那我就只用英文，以避免可能发生的转换问题。如果打算让用
户自己在现有的数据库上做2次开发，还是约定使用汉字，因为现在的开发人员并不是
很敬业，文档和代码并不一定完全同步，考虑到后期还是要求使用汉字吧，这样至少
代码的可读性还可以。
用户自己维护数据库，那我就只用英文，以避免可能发生的转换问题。如果打算让用
户自己在现有的数据库上做2次开发，还是约定使用汉字，因为现在的开发人员并不是
很敬业，文档和代码并不一定完全同步，考虑到后期还是要求使用汉字吧，这样至少
代码的可读性还可以。
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
to tseug，我不赞成使用汉字。
原因：
1、我使用的是Sco下Oracle 7.3.4开发，其本身没有安装汉字系统，服务器上维护不方便。——这不是主要原因
2、尽量使用E文的，因为可以更加通用，能够基本适合任何数据库——虽然移植到别的数据库一般是一句空话
3、数据库除了SQL Server对中文可能支持的比较好外，其他的包括Oracle在内的我都不放心，Select 可以，但是存储过程中呢？其他ProC中呢？——自我之见
4、程序员不敬业，没有达到文档和代码的同步，甚至很多代码根本没有注释，我觉得这个是软件管理＋软件工程的问题。
5、让用户直接维护数据库，我十分不推荐，虽然我们也有类似情况，但是我推荐如果可能，尽量给用户提供一个小的程序来维护数据库，哪怕是简单的一个执行SQL语句的呢。
6、个人支持使用E文来命名数据库以及字段，使用E文有两种办法：
A。E文含义，对于通用的程序比较使用，或者说对于使用数据库表比较少的程序使用。
B。使用中文拼音字头，这个对于比较多的数据库表有用。
两者对比就不用说了，一个是比较容易理解，好记忆，另一个是能够相对规范化一些。
就这些，欢迎探讨。
原因：
1、我使用的是Sco下Oracle 7.3.4开发，其本身没有安装汉字系统，服务器上维护不方便。——这不是主要原因
2、尽量使用E文的，因为可以更加通用，能够基本适合任何数据库——虽然移植到别的数据库一般是一句空话
3、数据库除了SQL Server对中文可能支持的比较好外，其他的包括Oracle在内的我都不放心，Select 可以，但是存储过程中呢？其他ProC中呢？——自我之见
4、程序员不敬业，没有达到文档和代码的同步，甚至很多代码根本没有注释，我觉得这个是软件管理＋软件工程的问题。
5、让用户直接维护数据库，我十分不推荐，虽然我们也有类似情况，但是我推荐如果可能，尽量给用户提供一个小的程序来维护数据库，哪怕是简单的一个执行SQL语句的呢。
6、个人支持使用E文来命名数据库以及字段，使用E文有两种办法：
A。E文含义，对于通用的程序比较使用，或者说对于使用数据库表比较少的程序使用。
B。使用中文拼音字头，这个对于比较多的数据库表有用。
两者对比就不用说了，一个是比较容易理解，好记忆，另一个是能够相对规范化一些。
就这些，欢迎探讨。
E
eachbuilder
Unregistered / Unconfirmed
GUEST, unregistred user!
MS SQL Server 2000 支持汉字字段，Oracle 好像对汉字的兼容性不好（不大清楚），但是
建议最好用英文字段，并用匈牙利命名法命名，一目了然。注意，与系统关键字同名字段要
加[]，但最好避免使用。
建议最好用英文字段，并用匈牙利命名法命名，一目了然。注意，与系统关键字同名字段要
加[]，但最好避免使用。
X
xeen
Unregistered / Unconfirmed
GUEST, unregistred user!
尽量不用汉字，我们用的很多系统都是基于英文的。用汉字有可能
遇到很多兼容性问题.
遇到很多兼容性问题.
C
Crosman
Unregistered / Unconfirmed
GUEST, unregistred user!
用e文，用汉字会s人的
X
xianjun
Unregistered / Unconfirmed
GUEST, unregistred user!
用汉字好维护，再加上一些（个别特殊用途的字段）字段注释，编程及开发存储过程时
一般都不用什么对照表之类的文档了，一目了然。
>>Oracle 好像对汉字的兼容性不好
这样的说法是毫无根据的，如果非要说不好，只能说是你用得不好罢了。 []
一般都不用什么对照表之类的文档了，一目了然。
>>Oracle 好像对汉字的兼容性不好
这样的说法是毫无根据的，如果非要说不好，只能说是你用得不好罢了。 [
]
T
tseug
Unregistered / Unconfirmed
GUEST, unregistred user!
>to tseug，我不赞成使用汉字。
>原因：
>1、我使用的是Sco下Oracle 7.3.4开发，其本身没有安装汉字系统，服务器上维护不方便。——这不是主要原因
如果是这样的环境那必须用英文。
>2、尽量使用E文的，因为可以更加通用，能够基本适合任何数据库——虽然移植到别的数据库一般是一句空话
以目前的实践来看, 很少有系统要在数据库间移植, 如果初期采用Oracle的话就更不可能了.
>3、数据库除了SQL Server对中文可能支持的比较好外，其他的包括Oracle在内的我都不放心，Select 可以，但是存储过程中呢？其他ProC中呢？——自我之见
我在DB2, Oracle上使用过没有问题.
>4、程序员不敬业，没有达到文档和代码的同步，甚至很多代码根本没有注释，我觉得这个是软件管理＋软件工程的问题。
这个的确是管理问题, 但也很现实. 不过如果需求分析时明确要求, 总比日后有麻烦强, 况且用汉字很符合一些非专业
人员的思维, 更能够准确的描述用户需求.
>5、让用户直接维护数据库，我十分不推荐，虽然我们也有类似情况，但是我推荐如果可能，尽量给用户提供一个小的程序
>来维护数据库，哪怕是简单的一个执行SQL语句的呢。
维护工具是必需的，但还要提供高级的接口，如果用汉字，用户就很容易理解，可以自己写SQL；
>6、个人支持使用E文来命名数据库以及字段，使用E文有两种办法：
>A。E文含义，对于通用的程序比较使用，或者说对于使用数据库表比较少的程序使用。
支持
>B。使用中文拼音字头，这个对于比较多的数据库表有用。
强烈反对，1年后你在看自己的表结构，就理解了。说个例子, 以前做银行项目时，有这么个表
LSLSZ，开始大家都以为是临时流水帐，过了好久几年前的一个负责系统设计说了大家才知道是
流水流水帐，前两个之母是类别。
>两者对比就不用说了，一个是比较容易理解，好记忆，另一个是能够相对规范化一些。
>就这些，欢迎探讨。
>原因：
>1、我使用的是Sco下Oracle 7.3.4开发，其本身没有安装汉字系统，服务器上维护不方便。——这不是主要原因
如果是这样的环境那必须用英文。
>2、尽量使用E文的，因为可以更加通用，能够基本适合任何数据库——虽然移植到别的数据库一般是一句空话
以目前的实践来看, 很少有系统要在数据库间移植, 如果初期采用Oracle的话就更不可能了.
>3、数据库除了SQL Server对中文可能支持的比较好外，其他的包括Oracle在内的我都不放心，Select 可以，但是存储过程中呢？其他ProC中呢？——自我之见
我在DB2, Oracle上使用过没有问题.
>4、程序员不敬业，没有达到文档和代码的同步，甚至很多代码根本没有注释，我觉得这个是软件管理＋软件工程的问题。
这个的确是管理问题, 但也很现实. 不过如果需求分析时明确要求, 总比日后有麻烦强, 况且用汉字很符合一些非专业
人员的思维, 更能够准确的描述用户需求.
>5、让用户直接维护数据库，我十分不推荐，虽然我们也有类似情况，但是我推荐如果可能，尽量给用户提供一个小的程序
>来维护数据库，哪怕是简单的一个执行SQL语句的呢。
维护工具是必需的，但还要提供高级的接口，如果用汉字，用户就很容易理解，可以自己写SQL；
>6、个人支持使用E文来命名数据库以及字段，使用E文有两种办法：
>A。E文含义，对于通用的程序比较使用，或者说对于使用数据库表比较少的程序使用。
支持
>B。使用中文拼音字头，这个对于比较多的数据库表有用。
强烈反对，1年后你在看自己的表结构，就理解了。说个例子, 以前做银行项目时，有这么个表
LSLSZ，开始大家都以为是临时流水帐，过了好久几年前的一个负责系统设计说了大家才知道是
流水流水帐，前两个之母是类别。
>两者对比就不用说了，一个是比较容易理解，好记忆，另一个是能够相对规范化一些。
>就这些，欢迎探讨。
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
B。使用中文拼音字头，这个对于比较多的数据库表有用。
采用这个确实是仁着见仁，智着见智的。确实存在你说的那个不容易记忆的问题，但是开发的时候出错的几率比使用E文的强的多。
尤其是当客户的领域很偏的时候，字段名称都很怪，这个时候使用E文很难记忆。还有，当设计的比如流水号比较多的种类的时候，使用其他命名方式会将人搞的晕头转向的。
很容易出错。
所以，我们最终选择了使用拼音字头的方案。目前正处于项目中间，感觉不到问题，而且一拿出来SCRWTZDH什么的，就知道是什么意思了。已经熟悉了。
采用这个确实是仁着见仁，智着见智的。确实存在你说的那个不容易记忆的问题，但是开发的时候出错的几率比使用E文的强的多。
尤其是当客户的领域很偏的时候，字段名称都很怪，这个时候使用E文很难记忆。还有，当设计的比如流水号比较多的种类的时候，使用其他命名方式会将人搞的晕头转向的。
很容易出错。
所以，我们最终选择了使用拼音字头的方案。目前正处于项目中间，感觉不到问题，而且一拿出来SCRWTZDH什么的，就知道是什么意思了。已经熟悉了。
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
>>维护工具是必需的，但还要提供高级的接口，如果用汉字，用户就很容易理解，可以自己写SQL；
这个我还是一再强调，我反对最终客户直接对数据库表操作，一来不应该让客户操作数据库表。
二来，很容易将数据库弄乱，搞的程序乱崩差，找不到问题。
这个我还是一再强调，我反对最终客户直接对数据库表操作，一来不应该让客户操作数据库表。
二来，很容易将数据库弄乱，搞的程序乱崩差，找不到问题。
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
>>LSLSZ，开始大家都以为是临时流水帐，过了好久几年前的一个负责系统设计说了大家才知道是
流水流水帐，前两个之母是类别
这个说实话，有点不可思议，开发系统一般的表结构都是使用数据库建模工具设计的，里面含有字段名称的E文对照。
直接看一下就清楚了。绝对不应该也不可能坐在几年或者过一段时间才知道。
还有，如果配合建模工具使用，字段的命名其实使用什么都不是特别重要，只要不容易错就可以。
字段含义是什么，到里面一查就OK了。
流水流水帐，前两个之母是类别
这个说实话，有点不可思议，开发系统一般的表结构都是使用数据库建模工具设计的，里面含有字段名称的E文对照。
直接看一下就清楚了。绝对不应该也不可能坐在几年或者过一段时间才知道。
还有，如果配合建模工具使用，字段的命名其实使用什么都不是特别重要，只要不容易错就可以。
字段含义是什么，到里面一查就OK了。
哈
哈利波特
Unregistered / Unconfirmed
GUEST, unregistred user!
比一比就知道了！呵呵
T
tseug
Unregistered / Unconfirmed
GUEST, unregistred user!
>>LSLSZ，开始大家都以为是临时流水帐，过了好久几年前的一个负责系统设计说了大家才知道是
> 流水流水帐，前两个之母是类别
>这个说实话，有点不可思议，开发系统一般的表结构都是使用数据库建模工具设计的，里面含有字段名称的E文对照。
>直接看一下就清楚了。绝对不应该也不可能坐在几年或者过一段时间才知道。
>还有，如果配合建模工具使用，字段的命名其实使用什么都不是特别重要，只要不容易错就可以。
>字段含义是什么，到里面一查就OK
做数据库如果涉及大量表都是采用建模工具的，但是维护时并不是随时带着工具，尤其是一个系统运行几年后，
所以采用汉字描述就避免了这个问题。
> 流水流水帐，前两个之母是类别
>这个说实话，有点不可思议，开发系统一般的表结构都是使用数据库建模工具设计的，里面含有字段名称的E文对照。
>直接看一下就清楚了。绝对不应该也不可能坐在几年或者过一段时间才知道。
>还有，如果配合建模工具使用，字段的命名其实使用什么都不是特别重要，只要不容易错就可以。
>字段含义是什么，到里面一查就OK
做数据库如果涉及大量表都是采用建模工具的，但是维护时并不是随时带着工具，尤其是一个系统运行几年后，
所以采用汉字描述就避免了这个问题。
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
>>做数据库如果涉及大量表都是采用建模工具的，但是维护时并不是随时带着工具，尤其是一个系统运行几年后，所以采用汉字描述就避免了这个问题。
这个就不好说了，如果使用了这种首字母的命名方式，基本上是需要带着的。我们目前也基本是随时带着这东西的。
这个就不好说了，如果使用了这种首字母的命名方式，基本上是需要带着的。我们目前也基本是随时带着这东西的。
T
tseug
Unregistered / Unconfirmed
GUEST, unregistred user!
>>维护工具是必需的，但还要提供高级的接口，如果用汉字，用户就很容易理解，可以自己写SQL；
>这个我还是一再强调，我反对最终客户直接对数据库表操作，一来不应该让客户操作数据库表。
>二来，很容易将数据库弄乱，搞的程序乱崩差，找不到问题。
这个问题使用密码和权限来控制的, 但是如果客户拥有权限, 但不知道字段含义就会出现你说的情况
如果他能够知道含义就能够尽量避免无意的改动. 当然, 故意破坏就没办法了, 那应该有管理来解决
>这个我还是一再强调，我反对最终客户直接对数据库表操作，一来不应该让客户操作数据库表。
>二来，很容易将数据库弄乱，搞的程序乱崩差，找不到问题。
这个问题使用密码和权限来控制的, 但是如果客户拥有权限, 但不知道字段含义就会出现你说的情况
如果他能够知道含义就能够尽量避免无意的改动. 当然, 故意破坏就没办法了, 那应该有管理来解决
Y
yzhshi
Unregistered / Unconfirmed
GUEST, unregistred user!
其实个人感觉很多时候将数据库对客户透明化还不如不让客户知道。
这个说法我相信会找来反对，但是是真心体会。
我们有一个客户就是，动不动就去手工改数据库，闹出问题了，就说你们程序如何如何。
还有，在程序开发阶段，他不仅仅关心程序对外的实现，而且还在关心程序内部如何如何。
指东道西，你不听她的呢，她有不满意，你听她的，又行不通，花费n长的时间争论、解释，也很难有结果。
当然，如果客户有真正的技术人员，对表结构修改、乃至提一些建议是很有用的，但是这种客户太少了，只是我们没有碰到过。
这个说法我相信会找来反对，但是是真心体会。
我们有一个客户就是，动不动就去手工改数据库，闹出问题了，就说你们程序如何如何。
还有，在程序开发阶段，他不仅仅关心程序对外的实现，而且还在关心程序内部如何如何。
指东道西，你不听她的呢，她有不满意，你听她的，又行不通，花费n长的时间争论、解释，也很难有结果。
当然，如果客户有真正的技术人员，对表结构修改、乃至提一些建议是很有用的，但是这种客户太少了，只是我们没有碰到过。
