フィールド名は日本語にするか、英語にするか
プログラミング的には、変数名と同じ感覚で英語なのかもしれないが、 英語にすると、日本語との変換データが必要になる。 ユーザーの感覚では日本語が当然わかりやすい。 特にユーザーがなんらかのUIを経て、テーブルやフィールドを 自由に作成する場合は日本語が良い? >>66 それなんだよね。 日本語は単語が多い。 しかも合成語も簡単に作れる。 英語だとそうはいかない。 文章になってしまう。 >53 >54 >66 >67 このへん重要な気が… 代表的なDBMSで日本語フィールド名を使うとどんなケースで 具合が悪いのか知りたくて覗いてるのだけれども、 全く具体例の出てこないね。このスレは。 せめて、ネットがらみだとドウだ、くらいの話題に展開しても いいはずだが。 Oralce/SQLServer + Delphi使いなのだが、フィールド名に英語が使われていると、たとえば 「MakerName」をQueryオブジェクトに取り込むとき、項目のオブジェクト名がQuery1MakerNameになって 直感的にコーディングがしやすくなるが、 「製造業者名」にしてしまうと、取り込まれたオブジェクト名がQuery1StringField1のようにIDEによって 適当につけられたNameになってしまい、コーディングのときDBの項目名とコードのオブジェクト名がまったく一致しない。 あとで直したり、あらたに対応表を作るのも大変。結局英語フィールドの方がストレスがたまらない。 .NETやJavaでDBアプリ組んだことがないからわからないけど、上手くやっているのかな? エンドユーザーが「日本語くれ」と言ってきたら、別名でビューを切って対応している。 見出しを付けるなら「IDEの思わぬ陥穽」となるね。 >>72 少なくともOracle9iではマテリアライズド・ビューが作れないことがある・・・orz ストアドやトリガー名も日本語でやってますが 何か問題でもあんの? VB と SQL Server で日本語使ってたけど問題なかった。 他の言語や DB だと色々大変なんだね。 日本語だと特別に考えなくても皆の認識が一致するから楽。 もちろん読んで(見て)分かり易い。 英文字だと変な英語だったりローマ字だったりでイライラする。 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='名簿'; 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='名簿'; マトモに日本語が扱える言語 マトモに日本語が扱えるデータベースエンジン これさえ揃っていれば、フィールド名が日本語でも全然支障ないね。 UNIX系OSから派生した、改行文字を”¥n”って書くタイプの言語は マトモに日本語が扱えないダメダメ言語が多いから、こんな無意味なスレが立つんだよね。 性別にsexは照れちゃう・・・。 チームにおなごがいるのでなおさら。 >>80 みたいな間抜けがいるから、こういうスレが勃つんじゃね? >>81 「gender」でどうよ? ちなみにウチのシステムの性別コードは 1.男 2.女 9.その他 って定義になってる。 性別コードは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 国際化(i18n)にいつでも対応できるよう、極力英語に統一するようにしてるけど、 いかんせん新幹線、その英単語に自信が無くて、人様に見せるのが恥ずかしい。 うーん、欧米との連携とかあるので英語。 結局、日本語は欧米の端末じゃそのままだと文字化けするからな。 いろいろな連携とか考えて、8文字に収まるように工夫している。 フィールド名の制限に引っかかるトラブルは 解析で出てくると面倒なので、触らないようにしている。 あんまりフリーにしていると、「○○日」なんてフィールド名が氾濫するし、 そのうち「○○日1」とかになってくるような気がして、 結局今英語で問題なことも日本語で同じように起きる気がするな。 >○○日1 分析段階から間違ってる気がするなw てかアトリビュート一覧管理しないのか? フィールド名を英語にしたいんだけど、 英語名が思いつかないよ。 みんなどうやって考えてるの? 申請書つくるにすら頭を抱える始末だよ。 CREATE TABLE MEIBO ( INT ID, VARCHAR NAMAE, VARCHAR TEL, VARCHAR ZIP, VARCHAR ADORESU ・・・ データの追加・更新・論理削除した日時を入れるカラム名は、みなさんどんな名前にしていますか? insert_datetime update_datetime delete_datetime ↑こういう感じでしょうか? 何か長ったらしいような気がしてます>< CRUDから頭文字を取って c_dt u_dt d_dt なんてものいいかな?と思いましたが、仕様書がないとすぐに連想できないですね>< 設計はともかく俺はdatetimeをdtmにするかどうかぐらいだな >>102 修正します。 挿入日時 更新日時 論理削除日時 さらに修正。 追加日時 更新日時 論理削除日時 つまり、>>99 の「仕様」に近いものほどよい。 ヘボン式にしろよ なんだよ syu とか jyu とか ヘボン式は例外ルール有りすぎ あとjyuって訓令じゃねえし、お前が無知なだけ >>105 アジア訛りで充分だろ 東洋人丸出しの顔で白人気取りに見えんのも逆に痛いし フィールド名やテーブル名に2バイト文字(日本語)を使うか、半角アルファベットを 使うかは、難しい問題だけど、半角英数だけにするなら、アルファベットは大文字に統一もしくは 小文字に統一する、2バイト文字使うなら、半角アルファベットは使わないは守らないといけないね。 半角アルファベットで、大文字・小文字を区別して混ぜて使うのは× Oracleの場合 "ABc"とか"あaあ"とかはやめてほしい。 ちなみに、おれの場合は、Oracleなら半角アルファベット、SQLServerやアクセスなら、全角日本語 かな 先ずはフィールド定義時にコメントをちゃんと入れて下さい>< nameだと思ったらnamaeだったりすると、もうやる気なくすわ ちとスレ違いではあるが、誰か知ってたら教えて欲しい。 SQLServer2005で、テーブル名、フィールド名ともすべて半角アルファベットで 定義されてるDBがあって、そのなかのいくつかのテーブルをJOINして ビューを作ってるんだけど、SQL文の中で、テーブル名 as ほにゃらら みたいに 別名を使うとき、別名に全角文字を使うのと、半角アルファベットを使うのとで、 パフォーマンスが変わる。全角の別名を使うと、パフォーマンスがガタ落ちする。 これってなんだろ? つまり SQLServer2005 が出来損ないということか? SQLServerは最強だお 製品C='XXX' 製品c='XXX' どちらでも問題ないよ >>36 と似てるけど、テーブル名に「ー」を使ったテーブルが読めないな。 oracle10・ole接続で表またはビューがありませんとなる。 ネイティブ接続、odbc接続だと読める。 oleドライバのバグだろうけど。 かっこつけて英語だとワコワカチなんで日本語。 病院用は英語。(DICOMとのからみで統一せんとワコワカチ) ↑みたいな悩みは日本人だけなんだろーか? 中東の人とかはどんなSQL書いてんだろ? ) 'obiem' ELBAT ETAERC ,regetni 'di' : : 的な? 英語に拒否反応を起こしてるのは日本人とフランス人だけ プロジェクトに外人も参加するなら英語にしといたほうが親切かもね。 中国人に聞いたらピンインで打つ奴も多いそうだけどw ってかさ、海外で利用するシステムなら、DBは半角英数字表記が一番だよねぇ? 現地の端末に日本語FEPが入ってるとは思えんので、何かあった時に、現地人が SQL書けないじゃないか。 未だに、大手企業の課長クラスの老害どもは、 英語やローマ字の短縮形を複数組み合わせて 暗号みたいな造語項目作って、別途、項目辞書で管理するのが 当たり前だと思ってやがる… 文字数や日本語の制限とかもう無いし、いいから早く氏んでくれよ。 海外利用どころか、日本でも通用しないよ… 英語に決まってんだろ! sql文を書く時、いらいらする。 そんなこともわからんのか。 >>135 何が短いの? いちいち日本語かどうか気にしながらSQLを書くことは、効率的ではない。 >>136 英語の場合、どうせスペルミスするからフィールド名は テーブル定義からコピペするだろ? 日本語でも英語でもSQL書く作業に代わりは無いよ。 英語フィールド名を確実に間違えず書ける奴なら話は別だが… >>138 おれは、カラム名はコピペしない、タイプする。 なぜなら、どうぜそのカラム名を覚える必要があるから、打って覚える。 だから、カラム名のときに、いちいち日本語にしながらSQLを打つのは、思考能力を妨げる何者でもない。 >>139 テーブル名、カラム名、データの他にいったい 何が残るというのだろう。 と言うかスキーマ・テーブル・カラム名を日本語にすると時々変な不具合とか出るのが嫌だ。 今は完全対応済、絶対大丈夫、と言われても、 何か信用できないところがあるのは俺だけだろうか? ローマ字読みが一番ムカツク というか、ほぼ確実に糞なプロジェクト、汎用性を持たせるか割り切るか、どちらもできなかったんだろうな 間違った英語が当ててあるのもかなり厳しいものがあるけどね 20数年日本語のテーブル名、フィールド名以外使ったことないな。 でもこのスレ見てると英数を使ってるところ多いんだね。 英語でも日本語でもわかりやすければなんでもいい 慣れだよ。 個人的には日本語が好き。 日本語名を使うとプログラムとか環境によってダブルクォートとか必要になったりする。 こっちで動いたプログラムがなんでこっちだと動かないんだ とか いろんな開発環境を想定した場合、半角英数字しかねーだろ? テーブル数が数百あるシステムとかだと半角英数字だと暗号みたいになって可読性がものすごく悪い。 日本語のほうが読みやすいしミス防止や作業効率UPのために日本語のほうがよい場合もある。 最近目が悪くなってきて半角英数字より全角日本語のほうが読みやすいし 日本語を使えるならできるだけ日本語を使うべきだと思うようになってきた。 >>149 と思ってるとやっぱりミドルウェアの予期せぬバグにやられる罠 >>150 Oracleの場合(他のDBは知らない) 表名や列名などのOracle Objectは半角英数字とアンスコなど一部 の特殊記号以外を使う場合、つまりマルチバイト文字などが含まれ るときはダブルクォーディング(ダブルクォートで囲む)しないと 動作保証されない。 たとえ今のバージョンでマルチバイト文字を含んだ表名や列名が エラーにならなくても、Oracleのパッチを適応したり、バージョン をアップするといきなりエラーになるかもしれない。 裏付けが欲しければ、OracleサポートやOracle Directに確認せよ。 動作保証外のことをやるのはその人の勝手だが、パッチを適応や バージョンアップ時に膨大な修正を強いられるだけ。 もっとも、そういう身勝手な設計をする人はバージョンアップ時に はトンズラしているだろうが。 >>151 15年以上まったく問題無かったのだが そうだとすると残念なことだ。 今後不具合が生じるような改変がなされる可能性はほぼゼロではないか。 技術的にマルチバイト文字を特別視する領域は見つからない。 環境やネットワーク、連携などにおいて比較的にクローズドな環境なら日本語使っても問題はほぼ無いし(あれば潰せばいいだけ)、そうでなく外部接続やフロントエンドの範囲が不明な場合や将来性において最後まで面倒が見れないような場合は2バイト禁止すればよい。 順序が逆だね。 ずーと、五年以上 "テーブル名" で使っていて、 ある時実は テーブル名 でも使えることに気づいて、 テストを重ねて、これなら大丈夫となって、 ダブルクオートを外した。サポートなんて、元々完全に 無視している。 >>156 みっともないから、 動作保証されないことに命をかけるのは止めた方がいい。 >>156 Oracleのバージョンを上げたらダブルクォーティングしていないテーブル名や 列名がいっせいにエラーになるかもしれないリスクを考えていないね。 その時はトンズラすりゃ良いってね。 いまさらそんなリスクはほとんどないし、命かけるとか馬鹿じゃねーの? まあがんばればいいんじゃね。 俺は、あほらしいからやらんけど。 あるお客さんの環境では、日本語を使っているを見たことがある。 でも、実際には、英語名のカラムにしたviewが別にあって、そっちを使うように指示が出ていたよ! >>162 Oracle7.2で機種依存文字を含んだマルチバイト文字でテーブル名や列名で 作ったもの(当然ダブルクォーティングなし)をOracle9.2に移行したら、 ダブルクォーティングしないとエラーになってとんでもない作業量になった と泣いていた人を知っている。 胃に穴があいて1年以上休んで、結局退社したそうだ。 何だかんだで英語のほうが無難ってことにうちの会社は行き着いてる。 そういや、日本語使ってる人はプログラム等でも変数に日本語使ってるのかな? >>164 SQL のフィールド名とかをダブルクォーテーションで囲むぐらいのことで 「とんでもない作業量」になるような設計だといずれ破綻してると思うよ。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる