TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
Microsoft SQL Server 総合スレ 12
RDBMS比較総合スレ 【サーバ】
MongoDB 1
Microsoft SQL Server 総合スレ 12
Oracle 質問総合スレ13
OODB - オブジェクト指向データベース
まじめにデータベースについて語るスレ
データベース破壊録カイジ
ADO.NETの質問・雑談スレ2
フィールド名は日本語にするか、英語にするか

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


1 ：2006/06/15 ～ 最終レス ：2018/02/14
プログラミング的には、変数名と同じ感覚で英語なのかもしれないが、
英語にすると、日本語との変換データが必要になる。

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

特にユーザーがなんらかの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
ぱっと思いつくのは、
①携帯
②古ーいシステムに引き渡すためにCSVを吐くという腐った案件
これらはデータ内容の問題だけど、
③Win98から古ーいツールを使ってアクセスしたいとユーザがわがままを言う

ま、①はともかく後のはどーでもいい話だと思ってるけどね。
ちなみに俺は>>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
なんてものいいかな？と思いましたが、仕様書がないとすぐに連想できないですね＞＜

100 ：
設計はともかく俺はdatetimeをdtmにするかどうかぐらいだな

101 ：
>>99
挿入時刻
修正時刻
削除時刻

102 ：
datetimeなら日時にすべき

103 ：
>>102
修正します。
挿入日時
更新日時
論理削除日時

104 ：
さらに修正。
追加日時
更新日時
論理削除日時

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

105 ：
結局訓令式ローマ字に落ち着いた。

106 ：
ヘボン式にしろよ
なんだよ syu とか jyu とか

107 ：
ヘボン式は例外ルール有りすぎ
あとjyuって訓令じゃねえし、お前が無知なだけ

108 ：
ヘボン式は論外。訓令式も半端。日本式で決まり。

109 ：
>>105
アジア訛りで充分だろ
東洋人丸出しの顔で白人気取りに見えんのも逆に痛いし

110 ：
>>109
誤爆？

111 ：
フィールド名やテーブル名に２バイト文字(日本語)を使うか、半角アルファベットを
使うかは、難しい問題だけど、半角英数だけにするなら、アルファベットは大文字に統一もしくは
小文字に統一する、２バイト文字使うなら、半角アルファベットは使わないは守らないといけないね。
半角アルファベットで、大文字・小文字を区別して混ぜて使うのは×

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


112 ：
先ずはフィールド定義時にコメントをちゃんと入れて下さい＞＜

113 ：
nameだと思ったらnamaeだったりすると、もうやる気なくすわ

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


115 ：
全角の別名を使ったから

116 ：
>>115
？

117 ：
>>116
全角の別名を使ったから

118 ：
>>117
？

119 ：
>>118
全角の別名使ったから


120 ：
全角の別名を使ったから


121 ：
つまり SQLServer2005 が出来損ないということか？

122 ：
SQLServerは最強だお
製品C='XXX'
製品ｃ='XXX'
どちらでも問題ないよ

123 ：
>>122
？

124 ：
>>36と似てるけど、テーブル名に「ー」を使ったテーブルが読めないな。
oracle10・ole接続で表またはビューがありませんとなる。
ネイティブ接続、odbc接続だと読める。
oleドライバのバグだろうけど。

125 ：
http://dubai.2ch.sc/test/read.cgi/emperor/1231694766/104

126 ：
かっこつけて英語だとﾜｺﾜｶﾁなんで日本語。

病院用は英語。（DICOMとのからみで統一せんとﾜｺﾜｶﾁ）

127 ：
↑みたいな悩みは日本人だけなんだろーか？
中東の人とかはどんなSQL書いてんだろ？
) 'obiem' ELBAT ETAERC
,regetni 'di'
:
:
的な？

128 ：
英語に拒否反応を起こしてるのは日本人とフランス人だけ

129 ：
プロジェクトに外人も参加するなら英語にしといたほうが親切かもね。

130 ：
中国人に聞いたらピンインで打つ奴も多いそうだけどｗ

131 ：
ってかさ、海外で利用するシステムなら、DBは半角英数字表記が一番だよねぇ？
現地の端末に日本語FEPが入ってるとは思えんので、何かあった時に、現地人が
SQL書けないじゃないか。

132 ：
なんで海外利用が前提になってるんだ

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


134 ：
英語に決まってんだろ！
sql文を書く時、いらいらする。
そんなこともわからんのか。

135 ：
日本語の方が短いし、入力時間も速いよ。

136 ：
>>135
何が短いの？
いちいち日本語かどうか気にしながらSQLを書くことは、効率的ではない。


137 ：
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 ：
>>136
英語の場合、どうせスペルミスするからフィールド名は
テーブル定義からコピペするだろ？
日本語でも英語でもＳＱＬ書く作業に代わりは無いよ。
英語フィールド名を確実に間違えず書ける奴なら話は別だが…


139 ：
>>138
おれは、カラム名はコピペしない、タイプする。
なぜなら、どうぜそのカラム名を覚える必要があるから、打って覚える。
だから、カラム名のときに、いちいち日本語にしながらSQLを打つのは、思考能力を妨げる何者でもない。


140 ：
>>139
テーブル名、カラム名、データの他にいったい
何が残るというのだろう。

141 ：
と言うかスキーマ・テーブル・カラム名を日本語にすると時々変な不具合とか出るのが嫌だ。
今は完全対応済、絶対大丈夫、と言われても、
何か信用できないところがあるのは俺だけだろうか？

142 ：
ローマ字読みが一番ムカツク
というか、ほぼ確実に糞なプロジェクト、汎用性を持たせるか割り切るか、どちらもできなかったんだろうな

143 ：
間違った英語が当ててあるのもかなり厳しいものがあるけどね

144 ：
TK_KBN

145 ：
漢字コードはバグのもと

146 ：
20数年日本語のテーブル名、フィールド名以外使ったことないな。
でもこのスレ見てると英数を使ってるところ多いんだね。


147 ：
英語でも日本語でもわかりやすければなんでもいい
慣れだよ。
個人的には日本語が好き。
日本語名を使うとプログラムとか環境によってダブルクォートとか必要になったりする。
こっちで動いたプログラムがなんでこっちだと動かないんだ　とか

148 ：
いろんな開発環境を想定した場合、半角英数字しかねーだろ？

149 ：
テーブル数が数百あるシステムとかだと半角英数字だと暗号みたいになって可読性がものすごく悪い。
日本語のほうが読みやすいしミス防止や作業効率ＵＰのために日本語のほうがよい場合もある。

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


150 ：
>>149
と思ってるとやっぱりミドルウェアの予期せぬバグにやられる罠

151 ：
>>150

Oracleの場合(他のDBは知らない)

表名や列名などのOracle Objectは半角英数字とアンスコなど一部
の特殊記号以外を使う場合、つまりマルチバイト文字などが含まれ
るときはダブルクォーディング(ダブルクォートで囲む)しないと
動作保証されない。

たとえ今のバージョンでマルチバイト文字を含んだ表名や列名が
エラーにならなくても、Oracleのパッチを適応したり、バージョン
をアップするといきなりエラーになるかもしれない。

裏付けが欲しければ、OracleサポートやOracle Directに確認せよ。

動作保証外のことをやるのはその人の勝手だが、パッチを適応や
バージョンアップ時に膨大な修正を強いられるだけ。

もっとも、そういう身勝手な設計をする人はバージョンアップ時に
はトンズラしているだろうが。



152 ：
>>151
15年以上まったく問題無かったのだが
そうだとすると残念なことだ。

153 ：
今後不具合が生じるような改変がなされる可能性はほぼゼロではないか。
技術的にマルチバイト文字を特別視する領域は見つからない。


154 ：
環境やネットワーク、連携などにおいて比較的にクローズドな環境なら日本語使っても問題はほぼ無いし(あれば潰せばいいだけ)、そうでなく外部接続やフロントエンドの範囲が不明な場合や将来性において最後まで面倒が見れないような場合は2バイト禁止すればよい。

155 ：
>>152
最初にサポートに確認しない方が悪い。

156 ：
順序が逆だね。
ずーと、五年以上 "テーブル名" で使っていて、
ある時実は テーブル名 でも使えることに気づいて、
テストを重ねて、これなら大丈夫となって、
ダブルクオートを外した。サポートなんて、元々完全に
無視している。

157 ：
>>156
みっともないから、
動作保証されないことに命をかけるのは止めた方がいい。


158 ：
>>156
Oracleのバージョンを上げたらダブルクォーティングしていないテーブル名や
列名がいっせいにエラーになるかもしれないリスクを考えていないね。

その時はトンズラすりゃ良いってね。

159 ：
いまさらそんなリスクはほとんどないし、命かけるとか馬鹿じゃねーの？

160 ：
>>159
ただの手抜き。


161 ：
まあがんばればいいんじゃね。

俺は、あほらしいからやらんけど。

162 ：
で、いままで日本語にしたことのあるやついるのか

163 ：
あるお客さんの環境では、日本語を使っているを見たことがある。
でも、実際には、英語名のカラムにしたviewが別にあって、そっちを使うように指示が出ていたよ！

164 ：
>>162
Oracle7.2で機種依存文字を含んだマルチバイト文字でテーブル名や列名で
作ったもの(当然ダブルクォーティングなし)をOracle9.2に移行したら、
ダブルクォーティングしないとエラーになってとんでもない作業量になった
と泣いていた人を知っている。

胃に穴があいて1年以上休んで、結局退社したそうだ。


165 ：
何だかんだで英語のほうが無難ってことにうちの会社は行き着いてる。
そういや、日本語使ってる人はプログラム等でも変数に日本語使ってるのかな？

166 ：
>>164
SQL のフィールド名とかをダブルクォーテーションで囲むぐらいのことで
「とんでもない作業量」になるような設計だといずれ破綻してると思うよ。

167 ：
>>164
サーバサイドなのかクライアントのアプリなのかは知らんが、その程度のことはデバックさえしっかり出来れば8割9割は自動化出来るだろ

168 ：
Oracle Directのセミナーで用意されるテキストのテーブルもマルチバイトの
テーブル名や列名をダブルクォーティングしていない。
自分の会社の看板に泥を塗っているやつらだ。

そういうのを見ていて 159 みたいに思う人が出てくるのであろう。


169 ：
アンカの付け方一つ知らないヤシが何言っても説得力ゼロだな

170 ：
どうせなんかのセミナーとかで聞きかじって得意になって >>151 を書い
たら馬鹿にされたので、顔真っ赤になってるだけだろ。

こんなことで「リスク」とか言っちゃってるのがほほえましいじゃないか。


171 ：
>>166
Oracle7.3で機種依存文字を大量に含んだ表名や列名があるシステムで
テーブル数が1,000以上ってのをOracle10.2.0へ移行するのを助っ人で
手伝ったことがある。

ダブルクォーティングの作業なんか予定になかったからスケジュールの
期限に間に合わなかった。今使われているどうかもわからないプログラム
も含めて、何万とあるSQLの動作確認も必要だったからメンバーを10人
補充してもらったが2ヶ月以上遅れた。

基本給より残業代の方が多かったが、マルチバイトで設計したテーブル
のシステムの依頼はすべて断っている。

172 ：
>>171
何でその程度のことを予知できなかったのかな。



173 ：
機種依存文字を大量に含んだテーブル名、フィールド名を
ダブルクォーティングすることには、誰も反対していないと
思うけど。


174 ：
>>170
マルチバイトでテーブル設計するのが格好良いと思っているのかな？
それもダブルクォートで囲まないで。

将来、会社に多大な出費を強いるかもしれないというリスクを負うこと
がわからないのか？

みっともない仕事はしないように。

175 ：
>>171
誰が作業工数見積もったか知らんが（まさかおまえじゃないよな？ｗ）、移行元のDBでマルチバイトが使われているにもかかわらず
ダブルクォーティング作業を工数に入れないのはただの凡ミスだろうが。基本中の基本だろ、そんなこと。

挙句逆切れとか、そんな業者、客の方が願い下げだろjk

176 ：
どうせ >>164=>>171 だろうけど...

> 何万とあるSQLの動作確認も必要だったから

Oracle 7.3 → Oracle 10i なら、動作確認はもともと必要だろ。

うそつくにしても素人杉。

177 ：
お客様の要望なら全角文字だろうが機種依存文字だろうが、使えば。
後で何が起ころうとそういう要求を出した側の責任。

1995年になってもわが社では年は2桁で持つことにしています、って
豪語していた会社もあったし。

178 ：
ダブルクォーツで囲むか囲まないかはたいした問題ではない。つまり、
だから日本語を採用するかしないかと言うような影響のでる事ではない。
読み易さ、使いやすさの問題。
日本語をフィールド名に採用するか、どうかは、データモデルと
プログラミング、オペレーション時の認識に関わる問題でずっと深刻。
一般論としては、フィールドとは集合の事だから、集合の要素の大半が
全角文字で表された場合は、フィールド名(属性)も自ずと全角文字が
使われることが予想される。それが自然ということ。


179 ：
> フィールドとは集合の事だから

珍説はチラシの裏にでも書いとけ。

180 ：
まとめると
日本語派→わかりやすさ重視
英数字派→互換性重視
ってことだよな。
結局、戦争に勝ったのにろくに英語教育しなかったアメリカが悪い。
占領した朝鮮にちゃんと日本語教育してやった日本はもっと評価されるべき。


181 ：
>>178
設計段階では、データベースってのは確かに集合でしかないわけだからあんたの言っていることは正しい。
ただし、実装段階でハードやらソフトの制約を受けた時点で、集合論のそのままを表現できるわけじゃないことぐらい分かるだろjk

182 ：
>>181
> データベースってのは確かに集合でしかない

珍説はチラシの裏にでも書いとけ。

183 ：
>>182
おいおい、人を勝手に自作自演にするなよｗ
T字形でもやれば、データモデルが集合論であることは良く分かる。

ただ、それをそのままデータ設計に持ち込むのは論外だと言っているまでで。
集合論からのアプローチは珍説でもなんでもない。

184 ：
フィールド名とデータの中身の区別もついてないのか...。

さすがに珍説を堂々と書ける椰子は頭の構造が違うな。

185 ：
中身に日本語が使えて、名前に制約があるのはソフトの問題。
本質的な話じゃない

186 ：
> 中身に日本語が使えて

中身の話なんて誰もしてない。

スレタイすら読めてないのか...。

187 ：
>>186
名前に日本語の制約がないなら、それでいいんじゃないの？

188 ：
>>186
文句が言いたいばかりに、自分の言っていることが支離滅裂になっていることも気がつかない？

189 ：
スレ違いを指摘されて逆切れ？

190 ：
論理的な話もできずに、派生した話をスレ違いというだけの低脳がなにを言うｗ

191 ：
最近は、唐突に違う話題を垂れ流すのを「派生」とか言うのか？

まあ、(リレーショナルデータベースの) データモデルが集合論に
関係しているって知ってるなんてしゅごいでちゅねぇ～

とか言われれば満足かな (ゲラ

192 ：
例えば、全角文字を含むフィールド名はダブルクォーティングしなくては
ならないような愚劣なRDBMSをどれだけ速やかに他のシステムに乗り換える
ことができるかが問われているということだ。

193 ：
ダブルクォートするよりシステムを乗り換える方が簡単なのか？

194 ：
それは場合によるけど、リプレースする有力な根拠になるということでしょう。

195 ：
2バイト項目名がダブルクォートされていないので、リプレースしましょうと提案するのか？ありえないだろｗ
2バイトOK（動作保障的に）なSQL Serverに乗り換えるとかそういうことか？

異なるRDBMSに載せかえるくらいなら、コスト的に素直にダブルクォーティングするか、DBの改修（2バイト名の1バイト化）しかありえん。

196 ：
>>195
場合による。

197 ：
愚劣で未来のない仕様のシステムは次回の選定で外されるということですねw


198 ：
その前にそんな提案をするお前が次回の選定ではずされるだろ

199 ：
クォートされたマルチバイト文字は通るが、されていなければ問題があるかもしれない
なんてパーサーは、一目見ただけで食欲をなくすようなすごいソースなんだろうな。

200 ：
OLracleのバージョンアップでCHARACTERSETをJA16SJISからAL32UTF8に変えたら
テーブル名、列名、ストアドプログラム名など30バイトの制限を超えたユーザー
があって、笑えた。


201 ：
SQL Serverなんて、キャラクターセット変えた程度でDB２との通信ができなくなったりする（ドライバがらみのバグ）んだぜ。
これが商用RDBMSとは到底思えないレベル。
こんなことでバグ取り1週間とか、正直笑えない。

202 ：
SQL Server 本体ならともかく、ドライバ、しかも DB2 との通信だろ。
馬鹿ですか？

203 ：
>>200　>>201
笑うことでリューマチの痛みが軽減するものだとのことでございます。

204 ：
>>202
SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して、それがキックにドライバで不具合、結果DB2との通信時に落ちる。

205 ：
>>204
> SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して

それは問題だ。
で、どのバージョンの話かな？
ソースつきで、頼むよ。

206 ：
>>205
ソースがあるぐらいのバグなら苦労しないだろｗ
SQL Server 2005 Workgroup Editionだったのは覚えているが、ビルド番号や該当するキャラクタセット、
DB2のバージョンやドライバの種類なんかは当時の備忘録紐解かないと覚えてない。
そして、それは面倒くさいから勘弁してくれｗ

207 ：
> ソースがあるぐらいのバグなら苦労しないだろ

はあ？ データ異常が発生するようなバグなら、HotFix なり ServicePack
が出てるだろ。何言ってるんだ？

> それは面倒くさいから勘弁してくれｗ

はいはい、言い訳乙。

208 ：
>>207
実務で扱ってれば、公式対応されるバグなんてごく一部なことぐらい分かりそうなもんだが。
おまえ、素人だろ。

209 ：
なんか状況が目に浮かぶようだw

>>208　「これバグだろ！！」
サポート　「はいはいw」


210 ：
ふーん、いきなり電話するんだ、サポートとやらにｗ
実際に仕事してる奴の台詞とは思えないなｗ

211 ：
バグだろうがこっちのミスだろうが、なにか自分らで解決できない問題が起きたら
サポートに電話するけどな、うちは。
バグだという確証が得られるまでサポートに連絡しないの？

212 ：
俺が知っている限りでは、当時（今もそのはずだが）SQL Serverに関する要望やバグを日本語で直接シアトルに電話でコンタクトする方法はなかったはずだが。
Visual Studio と .NETに関してはルートが存在していたが。

直接やりとりをできるサポートを知ってるなんて、MSの関係者ですか？ｗ

213 ：
何で直接シアトル？

214 ：
>>208
ああごめん、誰かさんの「脳内バグ」なら公式対応はしないだろうな (w

>>212
保守契約したらＭＳの関係者じゃなくても「サポートと直接やり取り
できる」よ。
て言うか、実務なら保守契約必須だと思うが...。

215 ：
それこそ場合によるだろうけど、
データベースの専門企業は別にすると
サポートを受けている方が少数派ではないか。

216 ：
データベースの専門企業？OracleやMS自身のことじゃぁないだろうからSIerのことか？
「サポート」って、いわゆるパートナー契約のことを言ってるのか？

もしかして、>>205が「ソース出せ」って言ったのをソースコードと勘違いして、シアトルに
電話するとか頓珍漢な話になったんじゃないだろうなw


217 ：
データセンタとかを言ってるんじゃないかな？

まあ、「サポートを受けている方が少数派」とか言ってるぐらいだから、
>>215 はこの手のお仕事したことないんだと思うよ。

218 ：
私の知っているSQL　Serverを使っている企業は、
業務ソフト入れたら、SQL Serverが入ってました。もったいないから、
ACCESSから乗り換えました、というような所ばかりで、
「実務なら保守契約必須」なんてことはなさそうだから、書いてみた。
私の言葉の選択が適切でなくて、話が通じなかったようだけど。


219 ：
社内の運用管理なのかデベロッパーなのかでバグ対応に関する認識が異なるんだろ。
運用管理者や社内の情シスなら、よほどの重大なバグでもない限りいずれかのタイミングでバグフィックスされれば構わない。

デベロッパーの立場になれば、納品までにバグが解消できなきゃまったく意味がない。

220 ：
>>218
> 業務ソフト入れたら、SQL Serverが入ってました。

そりゃその業務ソフトのメーカーが保証するからエンドユーザーが
SQL-Server の保守に入らんことは珍しくない。

> もったいないから、ACCESS から乗り換えました

意味わからんのだが...、業務ソフトが使ってる SQL-Server を別
の用途に使ってるってこと？

おれがその業務ソフトのメーカーなら、基本的に他の用途に使うの
はダメと言うけどね。

そもそもそんなことしなくても Access からの乗換えなら
Express で十分だと思うし。

>>219
社内システムでもバグが発生したら困るだろ。
たとえば、給与システムで次の給与の支払いまでにバグが解消でき
なきゃ大問題だぞ。

221 ：
>>220
年末調整でカバー。笑

222 ：
併記したら？

223 ：
以前はORACLEでもフィールド名やテーブル名を全角文字にするためには
ダブルクオートが必要だった記憶があるけれど、あれはいつ頃から必要なく
なったのだろう。

224 ：
ORACLE今もダブルクォート必須だよ。
そうしないと、同じ構文でも正常に動作したりしなかったりする。



225 ：
パッケージのバージョンアップでAL32UTF8にしか対応しなくなり、Oracle 9i SJIS → 11g AL32UTF8 に回されてしまった。
AL32UTF8 は半角カタカナとマルチバイト文字が1文字3バイトになるので文字列が桁あふれする可能性が出てくるので、あらかじめテーブルやストアド・プログラムの変数の桁数を見直さなければならない。
それ以前に、マルチバイト文字11文字以上で設計した、テーブル名、列名、索引名、ビュー名、ストアド・プログラム名、SYNONYM名、タイプ名などの定義がエラーになった。
-- //docs.oracle.com/cd/E16338_01/server.112/b56299/sql_elements008.htm#i27570

テーブル定義以外にプログラムの大修正が必要になった上に、CSVをOracleにI/Oする UTF_FILEで CONVERT キャラクタセットを変換したら文字化けするバグが見つかり、来月の納期を延ばしてもらうように管理者に依頼した。

226 ：
http://school2.2ch.sc/test/read.cgi/ojyuken/1053996625/

227 ：
★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い


10人に一人はカルトか外国人

「ガスライティング」で検索を！
...

229 ：
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

2EFN62JLAQ

230 ：2018/02/14
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

【KVS】 Key-Value Storeを勉強するスレ
Oracle 質問総合スレ13
【9i】オラクルマスターGOLDのスレ【10g】
データベースなんか作れるかよ！
ADO DAO など接続方法について
オラクルマスターsilverの資格試験について
DBを「でーびー」って言う人
いまの気持ちをSQLで表すスレ
【Java】H2 Database Engine【GCJ】
MySQL 5.0
--------------------
爬虫類飼育系YouTuber総合スレ PART5
【捏造マウント】赤井秀一信者アンチスレ12【設定泥棒】
パヨクも普通に馬鹿にしてもいい存在やろ？
ツイ民「マスクは転売屋がいた時の方がまだ買えた。今は朝から並ぶ年寄りが全部買ってしまう」←反論できる？ [304868982]
【ｴｽﾊﾟｰ】超初心者の質問に答えるスレ217
企業のWeb担当
(*^◯^*)わーいで変換できるんだ！
【大丈夫】月川当局者研究第77弾【少し回復60％】
【プリチャンアンチスレ】キラッとプリ☆チャンは超絶糞アニメ 53
【射殺せ】BLEACH 市丸ギン17kmや【神鎗】
公が事件起こしてから5年だけどもう出てくるんじゃね？
【ワなし】トラックボール コロコロ(((○ Part126
■フェデラーとナダルどっちが史上最強か？2■
濡れ場が多くて家族が気まずい雰囲気になった洋画
【JAL】50000FOP修行スレJL073便【JGC】
【みなさまのNHK】3日連続で「受信料」に理解求める番組放送…N国への危機感あらわ ★2
【リニューアル】Yahoo!パートナー【女性無料化】Part514
真・三國無双8 Part60
■日本でも喫煙運転の是非を議論すべし■ ５
ユーフォニアム総合スレ
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼