2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :NAME IS NULL:2006/06/15(木) 15:28:10 ID:uKjpjL1Y
プログラミング的には、変数名と同じ感覚で英語なのかもしれないが、
英語にすると、日本語との変換データが必要になる。

ユーザーの感覚では日本語が当然わかりやすい。

特にユーザーがなんらかのUIを経て、テーブルやフィールドを
自由に作成する場合は日本語が良い?

2 :NAME IS NULL:2006/06/15(木) 18:37:16 ID:???
アホ

3 :NAME IS NULL:2006/06/15(木) 20:05:00 ID:???
>特にユーザーがなんらかのUIを経て、テーブルやフィールドを
>自由に作成する

こんなものは作るな。研究・解析系は除くが、その場合は英語だわな。

4 :NAME IS NULL:2006/06/17(土) 00:10:43 ID:yTdcSlGF
人間が使うものだから、
わかり易いのが一番。

5 :NAME IS NULL:2006/06/17(土) 03:07:28 ID:9jZ+yuyk
それとオレあんな女とは絶対一緒になってやんねーからw
ばかばかしい。
命かけてもオレとは話すらするきないんだからほんとにばかばかしかったよ。


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

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

8 :NAME IS NULL:2006/06/19(月) 21:15:31 ID:???
ASP+SQLとかPHP+SQLとか
SQLの場合、たいてい他の言語と組み合わせて使うもんだから
相手の命名制限にもひっかかんないようにするのがおすすめ
あっちの変数名とこっちのフィールド名が全然ちがうと
デバッグが大変だし、改修も手間がかかる
grepで必ずどっちも引っかかるくらいだと後々改修が楽でよい

相手が日本語の変数名をゆるさないなら半角だけにした方が無難


9 :NAME IS NULL:2006/06/22(木) 00:15:31 ID:???
>1
>ユーザーの感覚では日本語が当然わかりやすい。
1部署のちっこいやつだと↑これが当てはまると思うが複数部署とか
複数業務にまたがると日本語名称だと部署毎の認識が違うとかでかえって
わかりにくくなると思われます。

>特にユーザーがなんらかのUIを経て、テーブルやフィールドを
>自由に作成する場合は日本語が良い?
ユーザさんは日本語名称で提示してくるそれをDB項目一覧とかから
ユニークに割り当てして承認もらって・・・ 
だけどそれが日本語だと大混乱になると思う。

販売管理事業部_商品管理_商品種別コード Char(10)
↑こんな項目名使いたいか? >>1

10 :NAME IS NULL:2006/06/22(木) 00:25:17 ID:???
>販売管理事業部_商品管理_商品種別コード
「Accessで課長が作ったんですけど」って見せられたやつはそんな感じだた

11 :NAME IS NULL:2006/06/22(木) 15:09:39 ID:t8z9cUkI
>>9
> ユーザさんは日本語名称で提示してくるそれをDB項目一覧とかから
> ユニークに割り当てして承認もらって・・・ 
> だけどそれが日本語だと大混乱になると思う。
>
> 販売管理事業部_商品管理_商品種別コード Char(10)
> ↑こんな項目名使いたいか? >>1

それが英語だとどうなるの?

12 :NAME IS NULL:2006/06/22(木) 15:40:50 ID:???
>>9
種別 だけでいいんじゃない。
General Database を指向するとそうなるのかな?

13 :NAME IS NULL:2006/06/22(木) 15:53:34 ID:65yugwU8
フィールド名に日本語使おうなどと考える奴は
なんでもかんでも自分のお脳味噌で管理しようとして
お脳味噌で管理できなくなると面倒くさくなって投げ出すタイプ。

フィールド名は”うろ覚え”で扱うようなものではなく
常に全てを覚えておけるものでもないのだから
日本語だろうが英語だろうが関係ない。

PG開発言語やDB定義名にいちいち日本語使いたがる奴は
効率化の着眼点が主観的過ぎてウンコ。

14 :NAME IS NULL:2006/06/22(木) 16:21:45 ID:???
本当に、
> 日本語だろうが英語だろうが関係ない。
のなら、普通に使って問題ないはずだが?

15 :NAME IS NULL:2006/06/22(木) 16:35:13 ID:???
英語もどきやローマ字だとどうちがうのだろうか。

16 :NAME IS NULL:2006/06/22(木) 16:39:34 ID:65yugwU8
日本語だろうが英語だろうが情報を区別する為の言語を変えたところで
たいした効率化にはつながらない。むしろ日本語による識別の場合
標準的な手法と異なることによるデメリットの方が大きい。

コンピュータにおいてマルチバイト文字の使用は
常に特別な問題を持っておりDBのフィールド名に日本語などを
使用すれば互換性や汎用性が著しく低下する恐れがある。

PG開発言語やDB定義名に日本語を使って喜ぶのは
物事を表面的・感覚的にしか理解できないゲーム脳のウンコ野郎だけ。

17 :NAME IS NULL:2006/06/22(木) 17:00:08 ID:???
データがマルチバイトを使用しているからなぁ。説得力ないね。
システム構築時に決定され、文字列長などが
関数演算の対象にならない定義名は何の問題もないはず。

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

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

20 :NAME IS NULL:2006/06/22(木) 17:40:59 ID:5Iq34pOu
互換性の問題を一切考えなくていいという仮定なら日本語を使うと思うが
現実的には心配が多々あるので無難に英数字を使う。

21 :NAME IS NULL:2006/06/22(木) 17:47:53 ID:???
データベース、フィールド名がUnicodeに対応していれば
使って問題ないんじゃね?

22 :NAME IS NULL:2006/06/22(木) 17:53:06 ID:???
>>21
Unicodeもコード体系は1つじゃないんだよ。

ttp://e-words.jp/w/Unicode.html

>現実的には心配が多々あるので無難に英数字を使う。
項目名称の不具合で悩みたくないし 結局、これなんだよね。 

23 :NAME IS NULL:2006/06/22(木) 18:29:26 ID:???
>>22
> Unicodeもコード体系は1つじゃないんだよ。
で?

どのコード体系だろうが、サポートされているUnicodeを使えば問題ないだろ。

24 :NAME IS NULL:2006/06/22(木) 19:10:09 ID:???
>>23
>> データベース、フィールド名がUnicodeに対応していれば
>どのコード体系だろうが、サポートされているUnicodeを使えば問題ないだろ。
SJIS・EUCでも何でも良いって事になるんじゃないの?


25 :NAME IS NULL:2006/06/22(木) 19:33:42 ID:???
「どうしても日本語にしろ!」という要望がきたらどうする?
シチュエーション的に避けられなかったので(アフォヴォケ営業とかいたので、どうしてもダメだった)
自分の場合は突っぱねて、「テーブルは触るな。触るとシステムが死ぬ」と言ってビュー(の項目名)を日本語にした。

26 :NAME IS NULL:2006/06/22(木) 19:59:16 ID:???
>>23
> SJIS・EUCでも何でも良いって事になるんじゃないの?
はぁ?

27 :NAME IS NULL:2006/06/22(木) 20:00:49 ID:???
とりあえず、データベースなどにバグがないのなら、
フィールド名は日本語のほうが楽に作れるよな。

バグがあるのがそもそも問題なことを理解しよう。

28 :NAME IS NULL:2006/06/22(木) 21:58:40 ID:bdFXJcIt
英語ローマ字の混在型。
ストアドを書く時、列が漢字だと、非常にコーディングしにくい。


29 :NAME IS NULL:2006/06/22(木) 23:24:49 ID:???
これって、漢字ひらがな入れちゃうか半角英数だけにするか
みたいな話なのか

KOKYAKUBANGOU にするか
CUSTOMERCODE にするか

みたいな話とは違うのか

30 :NAME IS NULL:2006/06/23(金) 01:09:27 ID:???
>>29
それも含めていいような気もするけど、今のところマルチバイト文字による定義名の是非が話題だね。

31 :NAME IS NULL:2006/06/23(金) 01:31:39 ID:???
フィールド名にマルチバイト文字が使えないDBMSなら、
しかたないんで英語か独逸語にする。
日本語のローマ字表記は読みづらいので個人的にキライ。

32 :NAME IS NULL:2006/06/23(金) 09:46:36 ID:???
コンピューターは欧米人の発明品で業界を牽引してるのも欧米人が中心。
マルチバイト文字の対応は遅れを取ることも多いから
日本語文字等の使用は特定の対人表示向けと割り切るべき。
定義情報の識別子に日本語など使うとろくなことはない。

javaなど識別子と関係無いところでも日本語問題があって
結局つきつめていくとエンコードに関わるメソッドで
文字セット指定できないと改善できないことがわかった。
後バージョンでのJVMで改善されてるのは承知していたが
その時システムで使用していたバージョンでは問題が解決できず
結局自分で代わりになるクラスを実装して日本語問題を片付けた。
ネットワークストリームに含まれる日本語ですら
そんな問題が出てしまうのに定義情報の識別子に
日本語使うなんて信じられない。

33 :NAME IS NULL:2006/06/23(金) 15:46:17 ID:???
JVMのマルチバイト対応にバグがあったという話なら、
それを確認せず採用する方に問題があるのではないか。

34 :NAME IS NULL:2006/06/23(金) 15:55:56 ID:???
UTF8使えばエンコード問題なんて全部解決じゃん。
いまどき、UTF8以外のエンコードで使うやつっているの?


35 :NAME IS NULL:2006/06/23(金) 17:00:03 ID:???
>>34
ぱっと思いつくのは、
@携帯
A古ーいシステムに引き渡すためにCSVを吐くという腐った案件
これらはデータ内容の問題だけど、
BWin98から古ーいツールを使ってアクセスしたいとユーザがわがままを言う

ま、@はともかく後のはどーでもいい話だと思ってるけどね。
ちなみに俺は>>19です。

36 :NAME IS NULL:2006/06/28(水) 22:57:00 ID:???
AccessからSQLServerに変えたときに「ー」を使ってたフィールドがらみのSQL文がみんな
エラーになってびっくらこいた。

37 :NAME IS NULL:2006/07/05(水) 18:03:42 ID:???
>>23
うん
ただ、それだとシステムの追加や入れ替えのとき
そのまま動かすには新しいシステムもそれに縛られちゃうから
システム構成を決められる権限も持ってないと
全部改修させられるリスクがあるよ


38 :NAME IS NULL:2006/07/15(土) 04:05:35 ID:rilGKiq6
遅レス・・

基本は英語にすべきじゃないかな?

まぁ、どこで製造するかにも寄るけど・・。
最近は、日本で設計したものを中国に投げるケースが多い・・。

中国人は、コメント等を日本語で書いてくれるが意味が不明なものも
多々ある・・。

英語で統一し、理解しやすいものに・・。

そもそも、PCは日本語より英語を使ってソフトを作ったほうが
処理も早いし・・。

39 :NAME IS NULL:2006/07/15(土) 17:01:47 ID:???
とりあえず、外部ツールなどもすべて日本語に対応してるのなら、
一度は日本語フィールド名使ってみたいかな。
判断はそれからだ


40 :NAME IS NULL:2006/07/16(日) 07:52:24 ID:???
自社開発の場合日本語を使用しない理由は全くない。

41 :NAME IS NULL:2006/07/25(火) 17:18:33 ID:lcoqexIT
PostgreSQLとSQLiteで日本語フィールド名を使ってる。複雑なクエリを後から見直す時でも
わかりやすくてとっても快適。


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

42 :NAME IS NULL:2006/07/25(火) 17:33:32 ID:???
UTF-8は情報量が1.5倍になる欠点がある。
ナローな回線だと致命的。

43 :NAME IS NULL:2006/07/25(火) 23:50:28 ID:???
> UTF-8は情報量が1.5倍になる欠点がある。
どうせ勘違いしているんだろうなw

44 :NAME IS NULL:2006/08/12(土) 00:53:29 ID:???
今まで見たフィールド名が日本語で構築されたDBにまともなものはなかったなあ。

45 :NAME IS NULL:2006/08/30(水) 00:20:53 ID:hS5RrkRv
プログラマー的には日本語にすべきでないと思う人が多いだろうが
その場の環境と客の要求に合わせて日本語にする事もある。
まともなDBなんて必要なくただ分かりやすければいいという場合もある。




46 :NAME IS NULL:2006/08/30(水) 11:10:40 ID:???
某大手の会計システムERPの内容を見るとオブジェクト名も項目名も全部英語だったが、
cT01みたいな暗号っぽいのばかりだったので、仕様書が不可欠だった(契約すればDB仕様書を入手できた)。
TAXPercentみたいな具体名に近い項目名がほしかったのだが・・・。

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

48 :NAME IS NULL:2006/08/31(木) 23:45:17 ID:???
仕様決めるときはレビューくらいしろw

49 :NAME IS NULL:2006/09/09(土) 18:56:43 ID:???
ストアドで日本語のフィールド名がずらずら書いてあるのを見て気づいた。

「記号みたいな英語名になってたときと変わらねー!」


50 :NAME IS NULL:2006/09/12(火) 12:47:43 ID:???
メンテナンス性という観点では仕様書がきちんとしてれば、どっちでもありじゃないかな。
でも、解析やデバッグなんかで、SQL打つときになるべく日本語入力切替とかしたくないから
やっぱり英語表記かな・・・個人的には。ということで

英語表記>>>日本語表記>ローマ字>>>>>>>>>>英語+ローマ字

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

52 :NAME IS NULL:2006/09/14(木) 09:53:28 ID:???
フィールド名が日本語で15文字超えるのは、ネーミングに問題があるような気がするけど
一般的に、日本語を英語やローマ字にしたらバイト数は増えるので
30バイトに無理やり名称を短縮したら、結果分かりづらくなる事が多くね?w

53 :NAME IS NULL:2006/09/14(木) 15:39:00 ID:???
ところで英語派の人たちに聞きたいんだけど、一般的にありがちなフィールド名、
まあなんでもいいけど例えば数量とか単価とか金額とか、
注文日とか納品日とか納品予定日とか請求日とか請求締日とか
半角アルファベットではみんなどんな命名してるの?

54 :NAME IS NULL:2006/09/17(日) 01:01:35 ID:???
外資系のシステム組んだことないの?英語の仕様書くらい読めないと

55 :NAME IS NULL:2006/09/17(日) 03:35:21 ID:???
マイナーな業務の名前を辞書引いて英語にしてたら、後で見てなんのフィールドかわからんかったよw

56 :NAME IS NULL:2006/09/17(日) 21:59:41 ID:???
>>54
御託は言い。
答えを言え。

57 :NAME IS NULL:2006/09/25(月) 15:52:13 ID:???
>>51
Oracle ならそもそも、日本語のオブジェクト名が使えるなんて保証してない。

58 :NAME IS NULL:2006/09/25(月) 17:35:29 ID:???
つーか、日本語のオブジェクト名が使えるなんて保障してるDBってあんの?

59 :NAME IS NULL:2006/09/25(月) 19:08:03 ID:???
こんなのしか見つからなかったが
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 :NAME IS NULL:2006/09/26(火) 14:34:45 ID:???
>>59
ちゃんとマニュアル嫁。

>非引用識別子にはデータベースキャラクタセットの英数字、
>アンダースコア(_)ドル記号($)およびシャープ記号(#)のみ
>含めることができます。
という事で、引用識別子としてなら日本語が使える。

…使えるんだが、テーブル名・カラム名のすべてをダブルクォーテーションで
括る必要があるわけで、これがまた見辛い事この上ない。オススメしない。
しかもデータベース文字セットがUTF-8だったりすると漢字1文字で3バイト。
その他(Oracleの問題じゃないが)、ミドルウェアやツールの問題で
文字化けしないとも限らないし。

61 :NAME IS NULL:2006/10/31(火) 22:57:30 ID:3tVRfpbQ
Oracle8.1.7〜10gR2だと全角文字の組み合わせでselectできないフィールドとかつくれちゃう不具合ありますよ

そのためにフィールド名を別の名前にした。"とかで囲ってもそんなフィールドないっていわれます。

62 :NAME IS NULL:2006/11/01(水) 09:57:15 ID:???
>>61
""で括っても駄目ってのは強烈だな。
上司や顧客への説得材料にしたいんで、よければ再現性のある具体例を教えて

63 :NAME IS NULL:2006/11/02(木) 09:23:17 ID:???
フィールド名を英単語で付けようと思ってるんだが
通常フィールド名で使うような単語を列記したようなサイト無いかな?

64 :NAME IS NULL:2006/11/02(木) 21:03:54 ID:rf5cSscl
日本語だと単語一つですむものを
英語にすると、熟語や文章になってしまう。
どうしたもんか。

65 :NAME IS NULL:2006/11/03(金) 12:15:26 ID:???
>>1
シネ

タマンネェーヨ!シネ

66 :NAME IS NULL:2006/11/18(土) 22:49:55 ID:???
元々英語派だったが、今は半角ローマ字派。
英語にすると、フィールド名にFromとかCurrencyとかが
避けられなくて、代わりの名前も浮かばないことがある。
勤務先では日本語できない外人でもKara、Tsukaを
使ってたりする。

67 :NAME IS NULL:2006/12/03(日) 21:14:59 ID:8cK8cWpw
>>66
それなんだよね。
日本語は単語が多い。
しかも合成語も簡単に作れる。

英語だとそうはいかない。
文章になってしまう。

68 :NAME IS NULL:2006/12/05(火) 16:31:56 ID:B4yTJgX9
実際、外国ではどうなのか?外人降臨しないかな?

69 :NAME IS NULL:2006/12/05(火) 16:47:45 ID:???
外国では日本語のフィールド名は使いません。

70 :NAME IS NULL:2006/12/06(水) 16:48:46 ID:???
>>69
そもそも日本語つかえませーんw

71 :NAME IS NULL:2007/03/14(水) 02:30:35 ID:0zI05T/K
>53
>54
>66
>67
このへん重要な気が…

72 :NAME IS NULL:2007/03/14(水) 06:36:52 ID:???
代表的なDBMSで日本語フィールド名を使うとどんなケースで
具合が悪いのか知りたくて覗いてるのだけれども、
全く具体例の出てこないね。このスレは。
せめて、ネットがらみだとドウだ、くらいの話題に展開しても
いいはずだが。

73 :NAME IS NULL:2007/03/14(水) 16:19:21 ID:???
Oralce/SQLServer + Delphi使いなのだが、フィールド名に英語が使われていると、たとえば
「MakerName」をQueryオブジェクトに取り込むとき、項目のオブジェクト名がQuery1MakerNameになって
直感的にコーディングがしやすくなるが、
「製造業者名」にしてしまうと、取り込まれたオブジェクト名がQuery1StringField1のようにIDEによって
適当につけられたNameになってしまい、コーディングのときDBの項目名とコードのオブジェクト名がまったく一致しない。
あとで直したり、あらたに対応表を作るのも大変。結局英語フィールドの方がストレスがたまらない。
.NETやJavaでDBアプリ組んだことがないからわからないけど、上手くやっているのかな?

エンドユーザーが「日本語くれ」と言ってきたら、別名でビューを切って対応している。

74 :NAME IS NULL:2007/03/14(水) 17:48:39 ID:???
見出しを付けるなら「IDEの思わぬ陥穽」となるね。

75 :NAME IS NULL:2007/03/19(月) 13:12:27 ID:???
>>72
少なくともOracle9iではマテリアライズド・ビューが作れないことがある・・・orz


76 :NAME IS NULL:2007/04/01(日) 01:55:01 ID:???
ストアドやトリガー名も日本語でやってますが
何か問題でもあんの?

77 :NAME IS NULL:2007/08/05(日) 12:37:28 ID:wwxWXJYl
VB と SQL Server で日本語使ってたけど問題なかった。
他の言語や DB だと色々大変なんだね。

日本語だと特別に考えなくても皆の認識が一致するから楽。
もちろん読んで(見て)分かり易い。

英文字だと変な英語だったりローマ字だったりでイライラする。


78 :NAME IS NULL:2007/08/22(水) 04:12:28 ID:SJy//8Ce
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 :NAME IS NULL:2007/08/22(水) 04:16:55 ID:SJy//8Ce
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 :NAME IS NULL:2007/08/22(水) 04:20:22 ID:SJy//8Ce
マトモに日本語が扱える言語
マトモに日本語が扱えるデータベースエンジン
これさえ揃っていれば、フィールド名が日本語でも全然支障ないね。

UNIX系OSから派生した、改行文字を”¥n”って書くタイプの言語は
マトモに日本語が扱えないダメダメ言語が多いから、こんな無意味なスレが立つんだよね。

81 :NAME IS NULL:2007/08/22(水) 05:01:47 ID:???
性別にsexは照れちゃう・・・。

チームにおなごがいるのでなおさら。

82 :NAME IS NULL:2007/08/22(水) 09:51:03 ID:???
>>79
なぜTABLE名が名簿でないの?

83 :NAME IS NULL:2007/08/25(土) 11:36:16 ID:AiFeupPe
>>82
スレタイ嫁

84 :NAME IS NULL:2007/08/27(月) 15:25:41 ID:???
>>80 みたいな間抜けがいるから、こういうスレが勃つんじゃね?

85 :NAME IS NULL:2007/08/27(月) 16:44:57 ID:???
まあまあ全角英数を使う人だから。

86 :NAME IS NULL:2007/09/10(月) 03:30:31 ID:???
>>81
「gender」でどうよ?
ちなみにウチのシステムの性別コードは

1.男
2.女
9.その他

って定義になってる。

87 :NAME IS NULL:2007/09/10(月) 12:02:32 ID:???
性別コードは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 :bPYeEOUH:2007/11/12(月) 17:16:19 ID:???
cuQIyv <a href="http://qbijodzqokqx.com/">qbijodzqokqx</a>, [url=http://dioqskksxrhh.com/]dioqskksxrhh[/url], [link=http://repnyrpyksqz.com/]repnyrpyksqz[/link], http://yrodtomfmakf.com/

89 :NAME IS NULL:2007/11/12(月) 19:37:40 ID:???
国際化(i18n)にいつでも対応できるよう、極力英語に統一するようにしてるけど、
いかんせん新幹線、その英単語に自信が無くて、人様に見せるのが恥ずかしい。

90 :NAME IS NULL:2007/11/26(月) 18:31:33 ID:???
うーん、欧米との連携とかあるので英語。
結局、日本語は欧米の端末じゃそのままだと文字化けするからな。
いろいろな連携とか考えて、8文字に収まるように工夫している。
フィールド名の制限に引っかかるトラブルは
解析で出てくると面倒なので、触らないようにしている。

あんまりフリーにしていると、「○○日」なんてフィールド名が氾濫するし、
そのうち「○○日1」とかになってくるような気がして、
結局今英語で問題なことも日本語で同じように起きる気がするな。

91 :NAME IS NULL:2007/12/29(土) 01:55:03 ID:???
>○○日1

分析段階から間違ってる気がするなw

てかアトリビュート一覧管理しないのか?

92 :NAME IS NULL:2008/01/26(土) 22:50:44 ID:???
フィールド名を英語にしたいんだけど、
英語名が思いつかないよ。

みんなどうやって考えてるの?
申請書つくるにすら頭を抱える始末だよ。

93 :NAME IS NULL:2008/01/27(日) 08:57:06 ID:???
>>92
つ「いい感じで英訳する。」


94 :NAME IS NULL:2008/02/01(金) 21:23:06 ID:UT00yD32
CREATE TABLE MEIBO (
INT ID,
VARCHAR NAMAE,
VARCHAR TEL,
VARCHAR ZIP,
VARCHAR ADORESU
・・・

95 :NAME IS NULL:2008/02/02(土) 00:51:15 ID:???
>>94
あるある

96 :NAME IS NULL:2008/02/03(日) 20:19:51 ID:???
VARCHARが前かよ。ばーかーw

97 :NAME IS NULL:2008/02/04(月) 12:13:44 ID:???
ZIPって可変長である必要があるのだろうか‥‥

98 :NAME IS NULL:2008/03/24(月) 14:14:21 ID:???
90210

99 :NAME IS NULL:2008/05/07(水) 17:33:52 ID:???
データの追加・更新・論理削除した日時を入れるカラム名は、みなさんどんな名前にしていますか?

insert_datetime
update_datetime
delete_datetime

↑こういう感じでしょうか?
何か長ったらしいような気がしてます><

CRUDから頭文字を取って
c_dt
u_dt
d_dt
なんてものいいかな?と思いましたが、仕様書がないとすぐに連想できないですね><

100 :NAME IS NULL:2008/05/08(木) 11:26:34 ID:???
設計はともかく俺はdatetimeをdtmにするかどうかぐらいだな

101 :NAME IS NULL:2008/05/17(土) 08:52:50 ID:???
>>99
挿入時刻
修正時刻
削除時刻

102 :NAME IS NULL:2008/05/20(火) 17:28:52 ID:???
datetimeなら日時にすべき

103 :NAME IS NULL:2008/05/21(水) 15:51:00 ID:???
>>102
修正します。
挿入日時
更新日時
論理削除日時

104 :NAME IS NULL:2008/05/21(水) 15:53:17 ID:???
さらに修正。
追加日時
更新日時
論理削除日時

つまり、>>99 の「仕様」に近いものほどよい。

105 :NAME IS NULL:2008/07/16(水) 15:04:06 ID:EcUIxzMa
結局訓令式ローマ字に落ち着いた。

106 :NAME IS NULL:2008/09/18(木) 19:17:39 ID:???
ヘボン式にしろよ
なんだよ syu とか jyu とか

107 :NAME IS NULL:2008/09/19(金) 09:08:56 ID:???
ヘボン式は例外ルール有りすぎ
あとjyuって訓令じゃねえし、お前が無知なだけ

108 :NAME IS NULL:2008/09/21(日) 15:44:13 ID:???
ヘボン式は論外。訓令式も半端。日本式で決まり。

109 :NAME IS NULL:2008/10/09(木) 18:12:14 ID:???
>>105
アジア訛りで充分だろ
東洋人丸出しの顔で白人気取りに見えんのも逆に痛いし

110 :NAME IS NULL:2008/10/09(木) 21:05:41 ID:???
>>109
誤爆?

111 :NAME IS NULL:2009/01/03(土) 00:15:19 ID:3emwlJX+
フィールド名やテーブル名に2バイト文字(日本語)を使うか、半角アルファベットを
使うかは、難しい問題だけど、半角英数だけにするなら、アルファベットは大文字に統一もしくは
小文字に統一する、2バイト文字使うなら、半角アルファベットは使わないは守らないといけないね。
半角アルファベットで、大文字・小文字を区別して混ぜて使うのは×

Oracleの場合
"ABc"とか"あaあ"とかはやめてほしい。
ちなみに、おれの場合は、Oracleなら半角アルファベット、SQLServerやアクセスなら、全角日本語
かな


112 :NAME IS NULL:2009/01/10(土) 10:05:45 ID:???
先ずはフィールド定義時にコメントをちゃんと入れて下さい><

113 :NAME IS NULL:2009/01/21(水) 04:04:36 ID:???
nameだと思ったらnamaeだったりすると、もうやる気なくすわ

114 :NAME IS NULL:2009/02/05(木) 01:14:23 ID:???
ちとスレ違いではあるが、誰か知ってたら教えて欲しい。
SQLServer2005で、テーブル名、フィールド名ともすべて半角アルファベットで
定義されてるDBがあって、そのなかのいくつかのテーブルをJOINして
ビューを作ってるんだけど、SQL文の中で、テーブル名 as ほにゃらら みたいに
別名を使うとき、別名に全角文字を使うのと、半角アルファベットを使うのとで、
パフォーマンスが変わる。全角の別名を使うと、パフォーマンスがガタ落ちする。
これってなんだろ?


115 :NAME IS NULL:2009/02/19(木) 13:22:28 ID:???
全角の別名を使ったから

116 :NAME IS NULL:2009/02/19(木) 20:07:41 ID:???
>>115


117 :NAME IS NULL:2009/02/19(木) 23:44:54 ID:???
>>116
全角の別名を使ったから

118 :NAME IS NULL:2009/02/20(金) 09:52:24 ID:???
>>117


119 :NAME IS NULL:2009/02/20(金) 19:17:10 ID:???
>>118
全角の別名使ったから


120 :NAME IS NULL:2009/02/20(金) 19:19:01 ID:???
全角の別名を使ったから


121 :NAME IS NULL:2009/02/21(土) 10:59:37 ID:???
つまり SQLServer2005 が出来損ないということか?

122 :NAME IS NULL:2009/03/14(土) 12:50:24 ID:+CMRFd3I
SQLServerは最強だお
製品C='XXX'
製品c='XXX'
どちらでも問題ないよ

123 :NAME IS NULL:2009/03/15(日) 07:56:01 ID:???
>>122


124 :NAME IS NULL:2009/03/17(火) 06:45:15 ID:t882uXmU
>>36と似てるけど、テーブル名に「ー」を使ったテーブルが読めないな。
oracle10・ole接続で表またはビューがありませんとなる。
ネイティブ接続、odbc接続だと読める。
oleドライバのバグだろうけど。

125 :NAME IS NULL:2009/03/21(土) 04:05:27 ID:???
http://dubai.2ch.net/test/read.cgi/emperor/1231694766/104

126 :NAME IS NULL:2009/04/06(月) 19:27:09 ID:Vb3wrAJR
かっこつけて英語だとワコワカチなんで日本語。

病院用は英語。(DICOMとのからみで統一せんとワコワカチ)

127 :NAME IS NULL:2009/04/24(金) 17:25:10 ID:???
↑みたいな悩みは日本人だけなんだろーか?
中東の人とかはどんなSQL書いてんだろ?
) 'obiem' ELBAT ETAERC
,regetni 'di'
:
:
的な?

128 :NAME IS NULL:2009/04/24(金) 19:40:38 ID:???
英語に拒否反応を起こしてるのは日本人とフランス人だけ

129 :NAME IS NULL:2009/04/26(日) 23:43:25 ID:???
プロジェクトに外人も参加するなら英語にしといたほうが親切かもね。

130 :NAME IS NULL:2009/06/13(土) 01:09:35 ID:???
中国人に聞いたらピンインで打つ奴も多いそうだけどw

131 :NAME IS NULL:2009/10/22(木) 02:03:00 ID:???
ってかさ、海外で利用するシステムなら、DBは半角英数字表記が一番だよねぇ?
現地の端末に日本語FEPが入ってるとは思えんので、何かあった時に、現地人が
SQL書けないじゃないか。

132 :NAME IS NULL:2009/10/22(木) 09:04:39 ID:???
なんで海外利用が前提になってるんだ

133 :NAME IS NULL:2009/12/16(水) 01:32:34 ID:6MmbHqTl
未だに、大手企業の課長クラスの老害どもは、
英語やローマ字の短縮形を複数組み合わせて
暗号みたいな造語項目作って、別途、項目辞書で管理するのが
当たり前だと思ってやがる…
文字数や日本語の制限とかもう無いし、いいから早く氏んでくれよ。
海外利用どころか、日本でも通用しないよ…


134 :NAME IS NULL:2009/12/16(水) 20:15:31 ID:???
英語に決まってんだろ!
sql文を書く時、いらいらする。
そんなこともわからんのか。

135 :NAME IS NULL:2009/12/16(水) 20:34:08 ID:???
日本語の方が短いし、入力時間も速いよ。

136 :NAME IS NULL:2009/12/17(木) 21:54:30 ID:???
>>135
何が短いの?
いちいち日本語かどうか気にしながらSQLを書くことは、効率的ではない。


137 :NAME IS NULL:2009/12/18(金) 13:26:38 ID:???
http://blogs.wankuma.com/kacchan6/archive/2007/08/15/90463.aspx
http://d.hatena.ne.jp/tgk/20070816
http://www.microsoft.com/japan/msdn/community/gdn/ShowPost-8478.htm
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=18616&forum=7

138 :NAME IS NULL:2009/12/18(金) 23:56:24 ID:+v0ZCbDz
>>136
英語の場合、どうせスペルミスするからフィールド名は
テーブル定義からコピペするだろ?
日本語でも英語でもSQL書く作業に代わりは無いよ。
英語フィールド名を確実に間違えず書ける奴なら話は別だが…


139 :NAME IS NULL:2009/12/19(土) 21:44:53 ID:???
>>138
おれは、カラム名はコピペしない、タイプする。
なぜなら、どうぜそのカラム名を覚える必要があるから、打って覚える。
だから、カラム名のときに、いちいち日本語にしながらSQLを打つのは、思考能力を妨げる何者でもない。


140 :NAME IS NULL:2009/12/19(土) 22:10:11 ID:???
>>139
テーブル名、カラム名、データの他にいったい
何が残るというのだろう。

141 :NAME IS NULL:2009/12/20(日) 22:56:44 ID:???
と言うかスキーマ・テーブル・カラム名を日本語にすると時々変な不具合とか出るのが嫌だ。
今は完全対応済、絶対大丈夫、と言われても、
何か信用できないところがあるのは俺だけだろうか?

142 :NAME IS NULL:2010/01/06(水) 17:08:31 ID:???
ローマ字読みが一番ムカツク
というか、ほぼ確実に糞なプロジェクト、汎用性を持たせるか割り切るか、どちらもできなかったんだろうな

143 :NAME IS NULL:2010/01/09(土) 15:53:29 ID:???
間違った英語が当ててあるのもかなり厳しいものがあるけどね

144 :NAME IS NULL:2010/01/19(火) 13:01:36 ID:???
TK_KBN

145 :NAME IS NULL:2010/03/06(土) 22:18:13 ID:paAZYSbY
漢字コードはバグのもと

146 :NAME IS NULL:2010/03/06(土) 23:19:08 ID:???
20数年日本語のテーブル名、フィールド名以外使ったことないな。
でもこのスレ見てると英数を使ってるところ多いんだね。


147 :NAME IS NULL:2010/03/07(日) 13:28:50 ID:???
英語でも日本語でもわかりやすければなんでもいい
慣れだよ。
個人的には日本語が好き。
日本語名を使うとプログラムとか環境によってダブルクォートとか必要になったりする。
こっちで動いたプログラムがなんでこっちだと動かないんだ とか

148 :NAME IS NULL:2010/03/10(水) 19:32:14 ID:???
いろんな開発環境を想定した場合、半角英数字しかねーだろ?

149 :NAME IS NULL:2010/03/12(金) 21:09:27 ID:???
テーブル数が数百あるシステムとかだと半角英数字だと暗号みたいになって可読性がものすごく悪い。
日本語のほうが読みやすいしミス防止や作業効率UPのために日本語のほうがよい場合もある。

最近目が悪くなってきて半角英数字より全角日本語のほうが読みやすいし
日本語を使えるならできるだけ日本語を使うべきだと思うようになってきた。


150 :NAME IS NULL:2010/03/14(日) 15:17:48 ID:DtdqkEWk
>>149
と思ってるとやっぱりミドルウェアの予期せぬバグにやられる罠

36 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)