フィールド名は日本語にするか、英語にするか

1 ：2006/06/15 〜 最終レス ：2013/02/03

プログラミング的には、変数名と同じ感覚で英語なのかもしれないが、
英語にすると、日本語との変換データが必要になる。
ユーザーの感覚では日本語が当然わかりやすい。
特にユーザーがなんらかのUIを経て、テーブルやフィールドを
自由に作成する場合は日本語が良い？

2 ：

ｱﾎ

3 ：

＞特にユーザーがなんらかのUIを経て、テーブルやフィールドを
＞自由に作成する
こんなものは作るな。研究・解析系は除くが、その場合は英語だわな。

4 ：

人間が使うものだから、
わかり易いのが一番。

5 ：

それとオレあんな女とは絶対一緒になってやんねーからｗ
ばかばかしい。
命かけてもオレとは話すらするきないんだからほんとにばかばかしかったよ。

6 ：

日本語か英語かじゃなくて、キャラクタベースで操作するときに全角半角の
切り替えを要求されるようなフィールド名にするかどうかだな。半角でも'hankaku'
は英語じゃなくて日本語だから。
で、キャラクタベースでの操作が要求されるようなら断然半角にするな。
（内部的にはすべてマルチバイトに移行しつつあるようだけど操作上は全角
半角が残りそうだし。）

7 ：

技術屋的に考えるなら英語一択だろ。
意外と使われてないのが、Oracleのコメント機能なんだけど、
あそこに日本語名とか備考入れてけばいいんじゃない？
Javaソースとjavadocみたいにソースと仕様書を一致させられるし。
sqlplusでもうちょいコメントが扱いやすければねー。

8 ：

ASP+SQLとかPHP+SQLとか
SQLの場合、たいてい他の言語と組み合わせて使うもんだから
相手の命名制限にもひっかかんないようにするのがおすすめ
あっちの変数名とこっちのフィールド名が全然ちがうと
デバッグが大変だし、改修も手間がかかる
grepで必ずどっちも引っかかるくらいだと後々改修が楽でよい
相手が日本語の変数名をゆるさないなら半角だけにした方が無難

9 ：

>1
>ユーザーの感覚では日本語が当然わかりやすい。
１部署のちっこいやつだと↑これが当てはまると思うが複数部署とか
複数業務にまたがると日本語名称だと部署毎の認識が違うとかでかえって
わかりにくくなると思われます。
>特にユーザーがなんらかのUIを経て、テーブルやフィールドを
>自由に作成する場合は日本語が良い？
ユーザさんは日本語名称で提示してくるそれをＤＢ項目一覧とかから
ユニークに割り当てして承認もらって・・・　
だけどそれが日本語だと大混乱になると思う。
販売管理事業部＿商品管理＿商品種別コード　Char(10)
↑こんな項目名使いたいか？　>>1

10 ：

＞販売管理事業部＿商品管理＿商品種別コード
「Accessで課長が作ったんですけど」って見せられたやつはそんな感じだた

11 ：

>>9
> ユーザさんは日本語名称で提示してくるそれをＤＢ項目一覧とかから
> ユニークに割り当てして承認もらって・・・　
> だけどそれが日本語だと大混乱になると思う。
>
> 販売管理事業部＿商品管理＿商品種別コード　Char(10)
> ↑こんな項目名使いたいか？　>>1
それが英語だとどうなるの？

12 ：

>>9
種別 だけでいいんじゃない。
General Database を指向するとそうなるのかな？

13 ：

フィールド名に日本語使おうなどと考える奴は
なんでもかんでも自分のお脳味噌で管理しようとして
お脳味噌で管理できなくなると面倒くさくなって投げ出すタイプ。
フィールド名は”うろ覚え”で扱うようなものではなく
常に全てを覚えておけるものでもないのだから
日本語だろうが英語だろうが関係ない。
PG開発言語やDB定義名にいちいち日本語使いたがる奴は
効率化の着眼点が主観的過ぎてウンコ。

14 ：

本当に、
> 日本語だろうが英語だろうが関係ない。
のなら、普通に使って問題ないはずだが？

15 ：

英語もどきやローマ字だとどうちがうのだろうか。

16 ：

日本語だろうが英語だろうが情報を区別する為の言語を変えたところで
たいした効率化にはつながらない。むしろ日本語による識別の場合
標準的な手法と異なることによるデメリットの方が大きい。
コンピュータにおいてマルチバイト文字の使用は
常に特別な問題を持っておりDBのフィールド名に日本語などを
使用すれば互換性や汎用性が著しく低下する恐れがある。
PG開発言語やDB定義名に日本語を使って喜ぶのは
物事を表面的・感覚的にしか理解できないゲーム脳のウンコ野郎だけ。

17 ：

データがマルチバイトを使用しているからなぁ。説得力ないね。
システム構築時に決定され、文字列長などが
関数演算の対象にならない定義名は何の問題もないはず。

18 ：

識別子とデータそのもののマルチバイト文字の使用では問題の範囲が全然違ってくるよ。
市販ツールとの相性なんかで大きな違いが出てくる。
フィールド名に日本語を使うということはSQL文に日本語を使うということで
クエリーツールなどとの相性を考えると余計な問題が増える可能性は高い。
フィールド名に日本語なんて使わないほうがいい。

19 ：

>>18
で、ツールやクライアントの相性問題をクリアできれば使っていいって思いますか？
俺はそういう立場を取るんだけど。もちろんツールのバージョンによって変わるような
あいまいな条件じゃなく、定義名の文字コードをちゃんと指定できる、というのが前提。
当たり前だけど、将来的に全然違うツールやクライアントを使う可能性が高ければ、
日本語は使わない。

20 ：

互換性の問題を一切考えなくていいという仮定なら日本語を使うと思うが
現実的には心配が多々あるので無難に英数字を使う。

21 ：

データベース、フィールド名がUnicodeに対応していれば
使って問題ないんじゃね？

22 ：

>>21
Unicodeもコード体系は１つじゃないんだよ。
ttp://e-words.jp/w/Unicode.html
>現実的には心配が多々あるので無難に英数字を使う。
項目名称の不具合で悩みたくないし　結局、これなんだよね。　

23 ：

>>22
> Unicodeもコード体系は１つじゃないんだよ。
で？
どのコード体系だろうが、サポートされているUnicodeを使えば問題ないだろ。

24 ：

>>23
>> データベース、フィールド名がUnicodeに対応していれば
>どのコード体系だろうが、サポートされているUnicodeを使えば問題ないだろ。
SJIS・EUCでも何でも良いって事になるんじゃないの？

25 ：

「どうしても日本語にしろ！」という要望がきたらどうする？
シチュエーション的に避けられなかったので（ｱﾌｫｳﾞｫｹ営業とかいたので､どうしてもダメだった）
自分の場合は突っぱねて、「テーブルは触るな。触るとシステムが死ぬ」と言ってビュー（の項目名）を日本語にした｡

26 ：

>>23
> SJIS・EUCでも何でも良いって事になるんじゃないの？
はぁ？

27 ：

とりあえず、データベースなどにバグがないのなら、
フィールド名は日本語のほうが楽に作れるよな。
バグがあるのがそもそも問題なことを理解しよう。

28 ：

英語ローマ字の混在型。
ストアドを書く時、列が漢字だと、非常にコーディングしにくい。

29 ：

これって、漢字ひらがな入れちゃうか半角英数だけにするか
みたいな話なのか
KOKYAKUBANGOU にするか
CUSTOMERCODE にするか
みたいな話とは違うのか

30 ：

>>29
それも含めていいような気もするけど、今のところマルチバイト文字による定義名の是非が話題だね。

31 ：

フィールド名にマルチバイト文字が使えないDBMSなら、
しかたないんで英語か独逸語にする。
日本語のローマ字表記は読みづらいので個人的にキライ。

32 ：

コンピューターは欧米人の発明品で業界を牽引してるのも欧米人が中心。
マルチバイト文字の対応は遅れを取ることも多いから
日本語文字等の使用は特定の対人表示向けと割り切るべき。
定義情報の識別子に日本語など使うとろくなことはない。
javaなど識別子と関係無いところでも日本語問題があって
結局つきつめていくとエンコードに関わるメソッドで
文字セット指定できないと改善できないことがわかった。
後バージョンでのJVMで改善されてるのは承知していたが
その時システムで使用していたバージョンでは問題が解決できず
結局自分で代わりになるクラスを実装して日本語問題を片付けた。
ネットワークストリームに含まれる日本語ですら
そんな問題が出てしまうのに定義情報の識別子に
日本語使うなんて信じられない。

33 ：

JVMのマルチバイト対応にバグがあったという話なら、
それを確認せず採用する方に問題があるのではないか。

34 ：

UTF8使えばエンコード問題なんて全部解決じゃん。
いまどき、UTF8以外のエンコードで使うやつっているの？

35 ：

>>34
ぱっと思いつくのは、
�@携帯
�A古ーいシステムに引き渡すためにCSVを吐くという腐った案件
これらはデータ内容の問題だけど、
�BWin98から古ーいツールを使ってアクセスしたいとユーザがわがままを言う
ま、�@はともかく後のはどーでもいい話だと思ってるけどね。
ちなみに俺は>>19です。

36 ：

AccessからSQLServerに変えたときに「ー」を使ってたフィールドがらみのSQL文がみんな
エラーになってびっくらこいた。

37 ：

>>23
うん
ただ、それだとシステムの追加や入れ替えのとき
そのまま動かすには新しいシステムもそれに縛られちゃうから
システム構成を決められる権限も持ってないと
全部改修させられるリスクがあるよ

38 ：

遅レス・・
基本は英語にすべきじゃないかな？
まぁ、どこで製造するかにも寄るけど・・。
最近は、日本で設計したものを中国に投げるケースが多い・・。
中国人は、コメント等を日本語で書いてくれるが意味が不明なものも
多々ある・・。
英語で統一し、理解しやすいものに・・。
そもそも、PCは日本語より英語を使ってソフトを作ったほうが
処理も早いし・・。

39 ：

とりあえず、外部ツールなどもすべて日本語に対応してるのなら、
一度は日本語フィールド名使ってみたいかな。
判断はそれからだ

40 ：

自社開発の場合日本語を使用しない理由は全くない。

41 ：

PostgreSQLとSQLiteで日本語フィールド名を使ってる。複雑なクエリを後から見直す時でも
わかりやすくてとっても快適。

本当は英語でフィールド名考えるのがめんどうなだけなんだけどw

42 ：

UTF-8は情報量が1.5倍になる欠点がある。
ナローな回線だと致命的。

43 ：

> UTF-8は情報量が1.5倍になる欠点がある。
どうせ勘違いしているんだろうなｗ

44 ：

今まで見たフィールド名が日本語で構築されたDBにまともなものはなかったなあ。

45 ：

プログラマー的には日本語にすべきでないと思う人が多いだろうが
その場の環境と客の要求に合わせて日本語にする事もある。
まともなＤＢなんて必要なくただ分かりやすければいいという場合もある。

46 ：

某大手の会計システムERPの内容を見るとオブジェクト名も項目名も全部英語だったが、
cT01みたいな暗号っぽいのばかりだったので､仕様書が不可欠だった（契約すればDB仕様書を入手できた）。
TAXPercentみたいな具体名に近い項目名がほしかったのだが・・・｡

47 ：

日本語は曖昧なところが多いからなぁ
複数の人が編集する時、似たような名前で別のフィールドを作るなんてことも十分考えられる
DBの構築・管理を一人若しくは十分に意思疎通が出来るグループなら日本語でもなんでもいいんじゃない？
逆に別の階の部署の人間が弄ったりするような場合だと、英語の方がいい場合が多いと思う

48 ：

仕様決めるときはレビューくらいしろｗ

49 ：

ストアドで日本語のフィールド名がずらずら書いてあるのを見て気づいた。
「記号みたいな英語名になってたときと変わらねー！」

50 ：

メンテナンス性という観点では仕様書がきちんとしてれば、どっちでもありじゃないかな。
でも、解析やデバッグなんかで、SQL打つときになるべく日本語入力切替とかしたくないから
やっぱり英語表記かな･･･個人的には。ということで
英語表記＞＞＞日本語表記＞ローマ字＞＞＞＞＞＞＞＞＞＞英語＋ローマ字

51 ：

oracleだとテーブル名、フィールド名は30byteまでですよね。
私の携わってるシステムでは、フィールド名に全角文字を使っているので、
全角15文字以下にしないといけない。項目名を日本語にすると、
意外と名称が長くなりがちです。
そうすると、無理やり名称を短縮して定義することになる。
結果分かりづらくなる事が多い。本末転倒です。
あまり勧められませんよ。

52 ：

フィールド名が日本語で１５文字超えるのは、ネーミングに問題があるような気がするけど
一般的に、日本語を英語やローマ字にしたらバイト数は増えるので
３０バイトに無理やり名称を短縮したら、結果分かりづらくなる事が多くね？ｗ

53 ：

ところで英語派の人たちに聞きたいんだけど、一般的にありがちなフィールド名、
まあなんでもいいけど例えば数量とか単価とか金額とか、
注文日とか納品日とか納品予定日とか請求日とか請求締日とか
半角アルファベットではみんなどんな命名してるの？

54 ：

外資系のシステム組んだことないの？英語の仕様書くらい読めないと

55 ：

マイナーな業務の名前を辞書引いて英語にしてたら、後で見てなんのフィールドかわからんかったよｗ

56 ：

>>54
御託は言い。
答えを言え。

57 ：

>>51
Oracle ならそもそも、日本語のオブジェクト名が使えるなんて保証してない。

58 ：

つーか、日本語のオブジェクト名が使えるなんて保障してるDBってあんの？

59 ：

こんなのしか見つからなかったが
ttp://www.oracle.co.jp/education/ou_enews_letter/try_om/vol25_fellow_a.html
「日本語のオブジェクト名が使えますよ」とも
「日本語のオブジェクト名は使えませんよ」とも
Oracleは明言してないような･･･

・A-Z、a-z、0-9、_、$、#以外は使用できません。
・A-Z、a-z、0-9、_、$、#以外を使用した場合は動作保障対象外です。
↑こういう書き方をしていない以上、マルチバイト文字だって文字なんだから
動作保障「している」と解釈されてもOracleは反論できないんじゃないの？

60 ：

>>59
ちゃんとマニュアル嫁。
>非引用識別子にはデータベースキャラクタセットの英数字、
>アンダースコア(_)ドル記号($)およびシャープ記号(#)のみ
>含めることができます。
という事で、引用識別子としてなら日本語が使える。
…使えるんだが、テーブル名・カラム名のすべてをダブルクォーテーションで
括る必要があるわけで、これがまた見辛い事この上ない。オススメしない。
しかもデータベース文字セットがUTF-8だったりすると漢字1文字で3バイト。
その他(Oracleの問題じゃないが)、ミドルウェアやツールの問題で
文字化けしないとも限らないし。

61 ：

Oracle8.1.7〜10gR2だと全角文字の組み合わせでselectできないフィールドとかつくれちゃう不具合ありますよ
そのためにフィールド名を別の名前にした。"とかで囲ってもそんなフィールドないっていわれます。

62 ：

>>61
""で括っても駄目ってのは強烈だな。
上司や顧客への説得材料にしたいんで、よければ再現性のある具体例を教えて

63 ：

フィールド名を英単語で付けようと思ってるんだが
通常フィールド名で使うような単語を列記したようなサイト無いかな？

64 ：

日本語だと単語一つですむものを
英語にすると、熟語や文章になってしまう。
どうしたもんか。

65 ：

>>1
ｼﾈ
ﾀﾏﾝﾈｪｰﾖ！ｼﾈ

66 ：

元々英語派だったが、今は半角ローマ字派。
英語にすると、フィールド名にFromとかCurrencyとかが
避けられなくて、代わりの名前も浮かばないことがある。
勤務先では日本語できない外人でもKara、Tsukaを
使ってたりする。

67 ：

>>66
それなんだよね。
日本語は単語が多い。
しかも合成語も簡単に作れる。
英語だとそうはいかない。
文章になってしまう。

68 ：

実際、外国ではどうなのか？外人降臨しないかな？

69 ：

外国では日本語のフィールド名は使いません。

70 ：

>>69
そもそも日本語つかえませーんw

71 ：

>53
>54
>66
>67
このへん重要な気が…

72 ：

代表的なDBMSで日本語フィールド名を使うとどんなケースで
具合が悪いのか知りたくて覗いてるのだけれども、
全く具体例の出てこないね。このスレは。
せめて、ネットがらみだとドウだ、くらいの話題に展開しても
いいはずだが。

73 ：

Oralce/SQLServer + Delphi使いなのだが､フィールド名に英語が使われていると､たとえば
「MakerName」をQueryオブジェクトに取り込むとき､項目のオブジェクト名がQuery1MakerNameになって
直感的にコーディングがしやすくなるが､
「製造業者名」にしてしまうと、取り込まれたオブジェクト名がQuery1StringField1のようにIDEによって
適当につけられたNameになってしまい、コーディングのときDBの項目名とコードのオブジェクト名がまったく一致しない｡
あとで直したり､あらたに対応表を作るのも大変｡結局英語フィールドの方がストレスがたまらない｡
.NETやJavaでDBアプリ組んだことがないからわからないけど､上手くやっているのかな？
エンドユーザーが「日本語くれ」と言ってきたら､別名でビューを切って対応している｡

74 ：

見出しを付けるなら「IDEの思わぬ陥穽」となるね。

75 ：

>>72
少なくともOracle9iではマテリアライズド・ビューが作れないことがある・・・orz

76 ：

ストアドやトリガー名も日本語でやってますが
何か問題でもあんの？

77 ：

VB と SQL Server で日本語使ってたけど問題なかった。
他の言語や DB だと色々大変なんだね。
日本語だと特別に考えなくても皆の認識が一致するから楽。
もちろん読んで（見て）分かり易い。
英文字だと変な英語だったりローマ字だったりでイライラする。

78 ：

CREATE TABLE `meibo` (
`id` integer,
`yuuzanamae` varchar(16) NOT NULL,
`pasuwardo` varchar(32) NOT NULL,
`nickname` varchar(32) NOT NULL,
`email` varchar(40) NOT NULL,
`namae` varchar(32) default NULL,
`seibetu` char(1) default NULL,
`tanjyobi` date default NULL,
`yuubin` varchar(8) default NULL,
`adoresu1` varchar(9) default NULL,
`adoresu2` varchar(255) default NULL,
`adoresu3` varchar(255) default NULL,
`tel1` varchar(13) default NULL,
`tel2` varchar(13) default NULL,
KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=sjis COMMENT='名簿';

79 ：

CREATE TABLE `meibo` (
`id` integer,
`account` varchar(16) NOT NULL,
`password` varchar(32) NOT NULL,
`ニックネーム` varchar(32) NOT NULL,
`email` varchar(40) NOT NULL,
`名前` varchar(32) default NULL,
`性別` char(1) default NULL,
`生年月日` date default NULL,
`郵便番号` varchar(8) default NULL,
`住所1` varchar(9) default NULL,
`住所2` varchar(255) default NULL,
`住所3` varchar(255) default NULL,
`電話番号` varchar(13) default NULL,
`携帯番号` varchar(13) default NULL,
KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=sjis COMMENT='名簿';

80 ：

マトモに日本語が扱える言語
マトモに日本語が扱えるデータベースエンジン
これさえ揃っていれば、フィールド名が日本語でも全然支障ないね。
ＵＮＩＸ系ＯＳから派生した、改行文字を”￥ｎ”って書くタイプの言語は
マトモに日本語が扱えないダメダメ言語が多いから、こんな無意味なスレが立つんだよね。

81 ：

性別にsexは照れちゃう・・・。
チームにおなごがいるのでなおさら。

82 ：

>>79
なぜTABLE名が名簿でないの?

83 ：

>>82
スレタイ嫁

84 ：

>>80 みたいな間抜けがいるから、こういうｽﾚが勃つんじゃね？

85 ：

まあまあ全角英数を使う人だから。

86 ：

>>81
「gender」でどうよ？
ちなみにウチのシステムの性別コードは
1.男
2.女
9.その他
って定義になってる。

87 ：

性別コードはISO 5218で決められているらしい。
0 = not known
1 = male
2 = female
9 = not specified
国内標準としてJIS X 0303でも決められてるけど、
0と9はないそうな。
参照。
tp://d.hatena.ne.jp/takahashim/20061223#p3

88 ：

cuQIyv <a href="http://qbijodzqokqx.com/">qbijodzqokqx</a>, [url=http://dioqskksxrhh.com/]dioqskksxrhh[/url], [link=http://repnyrpyksqz.com/]repnyrpyksqz[/link], http://yrodtomfmakf.com/

89 ：

国際化(i18n)にいつでも対応できるよう、極力英語に統一するようにしてるけど、
いかんせん新幹線、その英単語に自信が無くて、人様に見せるのが恥ずかしい。

90 ：

うーん、欧米との連携とかあるので英語。
結局、日本語は欧米の端末じゃそのままだと文字化けするからな。
いろいろな連携とか考えて、８文字に収まるように工夫している。
フィールド名の制限に引っかかるトラブルは
解析で出てくると面倒なので、触らないようにしている。
あんまりフリーにしていると、「○○日」なんてフィールド名が氾濫するし、
そのうち「○○日１」とかになってくるような気がして、
結局今英語で問題なことも日本語で同じように起きる気がするな。

91 ：

＞○○日１
分析段階から間違ってる気がするなｗ
てかアトリビュート一覧管理しないのか？

92 ：

フィールド名を英語にしたいんだけど、
英語名が思いつかないよ。
みんなどうやって考えてるの？
申請書つくるにすら頭を抱える始末だよ。

93 ：

>>92
つ「いい感じで英訳する。」

94 ：

CREATE TABLE MEIBO (
INT ID,
VARCHAR NAMAE,
VARCHAR TEL,
VARCHAR ZIP,
VARCHAR ADORESU
・・・

95 ：

>>94
あるある

96 ：

VARCHARが前かよ。ばーかーｗ

97 ：

ZIPって可変長である必要があるのだろうか‥‥

98 ：

90210

99 ：

データの追加・更新・論理削除した日時を入れるカラム名は、みなさんどんな名前にしていますか？
insert_datetime
update_datetime
delete_datetime
↑こういう感じでしょうか？
何か長ったらしいような気がしてます＞＜
CRUDから頭文字を取って
c_dt
u_dt
d_dt
なんてものいいかな？と思いましたが、仕様書がないとすぐに連想できないですね＞＜

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【新型】SQLServer2005【またか】 (265)
はじまりです。 (579)
【論理ファイル】ＡＳ４００ＤＢ【キューリー】 (242)
【無料DB】OpenOffice2.0?Base【Accessｲﾗﾈ】 (615)
ADO DAO など接続方法について (360)
頼むから正規化しろよ　第二正規形 (283)
--log9.info------------------
【千葉ロッテ】伊東勤監督の解任を要求する！part4 (855)
【ｱｲﾗｲｸﾉｳﾐｻﾝ】○○から猛虎魂を感じる【V38】 (465)
【西武】ハゲ渡辺久信監督の解任を要求する！Part6 (343)
今後バレンティンを超える強打者は出て来るのか？ (114)
■斎藤佑樹を馬鹿にしてた自称野球通ｗ（ｷﾘｯ■ (763)
そろそろみんなが忘れてしまったこと54 in野球 (572)
広島カープはこの先生キノコ雲35発目【レベル３】 (107)
中日・高木守道無能監督の解任を要求する！★41 (427)
【逆転】菅野智之Part6【新人王】 (190)
あっても読みたくないプロ野球選手の本2013 (655)
2013広島専用ドラフトスレ17巡目 (415)
中日の中日による中日の為の情報と補強119 (223)
★これからの野球界に起こりそうな珍事件予想ｽﾚ3★ (818)
チケット入手への道148枚目 (113)
２０１３年度沢村賞予想スレ (781)
13年パ・リーグ限定戦力分析スレPart55 (746)
--log55.com------------------
今年の兵庫県のバレーボール　小学生　その４
【日立リヴァーレ】佐藤美弥 選手応援スレ3【セッター】
神(女神)対応
●女子バレー会場でのカメラ撮影は禁止すべき！3●
チャレンジマッチ女子 2016/2017
チケット販売情報統一スレ　バレー版 5枚目
乳 ODA【小田桃香】10 トヨタ車体
兵庫の高校バレー