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

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

特にユーザーがなんらかのUIを経て、テーブルやフィールドを
自由に作成する場合は日本語が良い？
0102NAME IS NULL
垢版 |
2008/05/20(火) 17:28:52ID:???
datetimeなら日時にすべき
0103NAME IS NULL
垢版 |
2008/05/21(水) 15:51:00ID:???
>>102
修正します。
挿入日時
更新日時
論理削除日時
0104NAME IS NULL
垢版 |
2008/05/21(水) 15:53:17ID:???
さらに修正。
追加日時
更新日時
論理削除日時

つまり、>>99 の「仕様」に近いものほどよい。
0105NAME IS NULL
垢版 |
2008/07/16(水) 15:04:06ID:EcUIxzMa
結局訓令式ローマ字に落ち着いた。
0106NAME IS NULL
垢版 |
2008/09/18(木) 19:17:39ID:???
ヘボン式にしろよ
なんだよ syu とか jyu とか
0107NAME IS NULL
垢版 |
2008/09/19(金) 09:08:56ID:???
ヘボン式は例外ルール有りすぎ
あとjyuって訓令じゃねえし、お前が無知なだけ
0108NAME IS NULL
垢版 |
2008/09/21(日) 15:44:13ID:???
ヘボン式は論外。訓令式も半端。日本式で決まり。
0109NAME IS NULL
垢版 |
2008/10/09(木) 18:12:14ID:???
>>105
アジア訛りで充分だろ
東洋人丸出しの顔で白人気取りに見えんのも逆に痛いし
0111NAME IS NULL
垢版 |
2009/01/03(土) 00:15:19ID:3emwlJX+
フィールド名やテーブル名に２バイト文字(日本語)を使うか、半角アルファベットを
使うかは、難しい問題だけど、半角英数だけにするなら、アルファベットは大文字に統一もしくは
小文字に統一する、２バイト文字使うなら、半角アルファベットは使わないは守らないといけないね。
半角アルファベットで、大文字・小文字を区別して混ぜて使うのは×

Oracleの場合
"ABc"とか"あaあ"とかはやめてほしい。
ちなみに、おれの場合は、Oracleなら半角アルファベット、SQLServerやアクセスなら、全角日本語
かな
0112NAME IS NULL
垢版 |
2009/01/10(土) 10:05:45ID:???
先ずはフィールド定義時にコメントをちゃんと入れて下さい＞＜
0113NAME IS NULL
垢版 |
2009/01/21(水) 04:04:36ID:???
nameだと思ったらnamaeだったりすると、もうやる気なくすわ
0114NAME IS NULL
垢版 |
2009/02/05(木) 01:14:23ID:???
ちとスレ違いではあるが、誰か知ってたら教えて欲しい。
SQLServer2005で、テーブル名、フィールド名ともすべて半角アルファベットで
定義されてるDBがあって、そのなかのいくつかのテーブルをJOINして
ビューを作ってるんだけど、SQL文の中で、テーブル名 as ほにゃらら　みたいに
別名を使うとき、別名に全角文字を使うのと、半角アルファベットを使うのとで、
パフォーマンスが変わる。全角の別名を使うと、パフォーマンスがガタ落ちする。
これってなんだろ？
0115NAME IS NULL
垢版 |
2009/02/19(木) 13:22:28ID:???
全角の別名を使ったから
0120NAME IS NULL
垢版 |
2009/02/20(金) 19:19:01ID:???
全角の別名を使ったから
0121NAME IS NULL
垢版 |
2009/02/21(土) 10:59:37ID:???
つまり SQLServer2005 が出来損ないということか？
0122NAME IS NULL
垢版 |
2009/03/14(土) 12:50:24ID:+CMRFd3I
SQLServerは最強だお
製品C='XXX'
製品ｃ='XXX'
どちらでも問題ないよ
0124NAME IS NULL
垢版 |
2009/03/17(火) 06:45:15ID:t882uXmU
>>36と似てるけど、テーブル名に「ー」を使ったテーブルが読めないな。
oracle10・ole接続で表またはビューがありませんとなる。
ネイティブ接続、odbc接続だと読める。
oleドライバのバグだろうけど。
0126NAME IS NULL
垢版 |
2009/04/06(月) 19:27:09ID:Vb3wrAJR
かっこつけて英語だとﾜｺﾜｶﾁなんで日本語。

病院用は英語。（DICOMとのからみで統一せんとﾜｺﾜｶﾁ）
0127NAME IS NULL
垢版 |
2009/04/24(金) 17:25:10ID:???
↑みたいな悩みは日本人だけなんだろーか？
中東の人とかはどんなSQL書いてんだろ？
) 'obiem' ELBAT ETAERC
,regetni 'di'
:
:
的な？
0128NAME IS NULL
垢版 |
2009/04/24(金) 19:40:38ID:???
英語に拒否反応を起こしてるのは日本人とフランス人だけ
0129NAME IS NULL
垢版 |
2009/04/26(日) 23:43:25ID:???
プロジェクトに外人も参加するなら英語にしといたほうが親切かもね。
0130NAME IS NULL
垢版 |
2009/06/13(土) 01:09:35ID:???
中国人に聞いたらピンインで打つ奴も多いそうだけどｗ
0131NAME IS NULL
垢版 |
2009/10/22(木) 02:03:00ID:???
ってかさ、海外で利用するシステムなら、DBは半角英数字表記が一番だよねぇ？
現地の端末に日本語FEPが入ってるとは思えんので、何かあった時に、現地人が
SQL書けないじゃないか。
0132NAME IS NULL
垢版 |
2009/10/22(木) 09:04:39ID:???
なんで海外利用が前提になってるんだ
0133NAME IS NULL
垢版 |
2009/12/16(水) 01:32:34ID:6MmbHqTl
未だに、大手企業の課長クラスの老害どもは、
英語やローマ字の短縮形を複数組み合わせて
暗号みたいな造語項目作って、別途、項目辞書で管理するのが
当たり前だと思ってやがる…
文字数や日本語の制限とかもう無いし、いいから早く氏んでくれよ。
海外利用どころか、日本でも通用しないよ…
0134NAME IS NULL
垢版 |
2009/12/16(水) 20:15:31ID:???
英語に決まってんだろ！
sql文を書く時、いらいらする。
そんなこともわからんのか。
0135NAME IS NULL
垢版 |
2009/12/16(水) 20:34:08ID:???
日本語の方が短いし、入力時間も速いよ。
0136NAME IS NULL
垢版 |
2009/12/17(木) 21:54:30ID:???
>>135
何が短いの？
いちいち日本語かどうか気にしながらSQLを書くことは、効率的ではない。
0138NAME IS NULL
垢版 |
2009/12/18(金) 23:56:24ID:+v0ZCbDz
>>136
英語の場合、どうせスペルミスするからフィールド名は
テーブル定義からコピペするだろ？
日本語でも英語でもＳＱＬ書く作業に代わりは無いよ。
英語フィールド名を確実に間違えず書ける奴なら話は別だが…
0139NAME IS NULL
垢版 |
2009/12/19(土) 21:44:53ID:???
>>138
おれは、カラム名はコピペしない、タイプする。
なぜなら、どうぜそのカラム名を覚える必要があるから、打って覚える。
だから、カラム名のときに、いちいち日本語にしながらSQLを打つのは、思考能力を妨げる何者でもない。
0140NAME IS NULL
垢版 |
2009/12/19(土) 22:10:11ID:???
>>139
テーブル名、カラム名、データの他にいったい
何が残るというのだろう。
0141NAME IS NULL
垢版 |
2009/12/20(日) 22:56:44ID:???
と言うかスキーマ・テーブル・カラム名を日本語にすると時々変な不具合とか出るのが嫌だ。
今は完全対応済、絶対大丈夫、と言われても、
何か信用できないところがあるのは俺だけだろうか？
0142NAME IS NULL
垢版 |
2010/01/06(水) 17:08:31ID:???
ローマ字読みが一番ムカツク
というか、ほぼ確実に糞なプロジェクト、汎用性を持たせるか割り切るか、どちらもできなかったんだろうな
0143NAME IS NULL
垢版 |
2010/01/09(土) 15:53:29ID:???
間違った英語が当ててあるのもかなり厳しいものがあるけどね
0145NAME IS NULL
垢版 |
2010/03/06(土) 22:18:13ID:paAZYSbY
漢字コードはバグのもと
0146NAME IS NULL
垢版 |
2010/03/06(土) 23:19:08ID:???
20数年日本語のテーブル名、フィールド名以外使ったことないな。
でもこのスレ見てると英数を使ってるところ多いんだね。
0147NAME IS NULL
垢版 |
2010/03/07(日) 13:28:50ID:???
英語でも日本語でもわかりやすければなんでもいい
慣れだよ。
個人的には日本語が好き。
日本語名を使うとプログラムとか環境によってダブルクォートとか必要になったりする。
こっちで動いたプログラムがなんでこっちだと動かないんだ　とか
0148NAME IS NULL
垢版 |
2010/03/10(水) 19:32:14ID:???
いろんな開発環境を想定した場合、半角英数字しかねーだろ？
0149NAME IS NULL
垢版 |
2010/03/12(金) 21:09:27ID:???
テーブル数が数百あるシステムとかだと半角英数字だと暗号みたいになって可読性がものすごく悪い。
日本語のほうが読みやすいしミス防止や作業効率ＵＰのために日本語のほうがよい場合もある。

最近目が悪くなってきて半角英数字より全角日本語のほうが読みやすいし
日本語を使えるならできるだけ日本語を使うべきだと思うようになってきた。
0150NAME IS NULL
垢版 |
2010/03/14(日) 15:17:48ID:DtdqkEWk
>>149
と思ってるとやっぱりミドルウェアの予期せぬバグにやられる罠
0151NAME IS NULL
垢版 |
2010/10/01(金) 08:53:01ID:???
>>150

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

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

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

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

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

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

0152NAME IS NULL
垢版 |
2010/10/01(金) 19:21:43ID:???
>>151
15年以上まったく問題無かったのだが
そうだとすると残念なことだ。
0153NAME IS NULL
垢版 |
2010/10/02(土) 07:21:46ID:???
今後不具合が生じるような改変がなされる可能性はほぼゼロではないか。
技術的にマルチバイト文字を特別視する領域は見つからない。
0154NAME IS NULL
垢版 |
2010/10/03(日) 22:47:10ID:???
環境やネットワーク、連携などにおいて比較的にクローズドな環境なら日本語使っても問題はほぼ無いし(あれば潰せばいいだけ)、そうでなく外部接続やフロントエンドの範囲が不明な場合や将来性において最後まで面倒が見れないような場合は2バイト禁止すればよい。
0155NAME IS NULL
垢版 |
2010/10/19(火) 14:16:22ID:dBdSbcBS
>>152
最初にサポートに確認しない方が悪い。
0156NAME IS NULL
垢版 |
2010/10/19(火) 16:53:15ID:???
順序が逆だね。
ずーと、五年以上 "テーブル名" で使っていて、
ある時実は テーブル名 でも使えることに気づいて、
テストを重ねて、これなら大丈夫となって、
ダブルクオートを外した。サポートなんて、元々完全に
無視している。
0157NAME IS NULL
垢版 |
2010/10/20(水) 12:08:26ID:fiUikrto
>>156
みっともないから、
動作保証されないことに命をかけるのは止めた方がいい。
0158NULL IS NULL
垢版 |
2010/10/20(水) 18:47:30ID:???
>>156
Oracleのバージョンを上げたらダブルクォーティングしていないテーブル名や
列名がいっせいにエラーになるかもしれないリスクを考えていないね。

その時はトンズラすりゃ良いってね。
0159NAME IS NULL
垢版 |
2010/10/23(土) 09:43:48ID:???
いまさらそんなリスクはほとんどないし、命かけるとか馬鹿じゃねーの？
0161NAME IS NULL
垢版 |
2010/10/23(土) 20:00:10ID:???
まあがんばればいいんじゃね。

俺は、あほらしいからやらんけど。
0162NAME IS NULL
垢版 |
2010/10/24(日) 17:19:43ID:???
で、いままで日本語にしたことのあるやついるのか
0163NAME IS NULL
垢版 |
2010/10/24(日) 17:36:56ID:???
あるお客さんの環境では、日本語を使っているを見たことがある。
でも、実際には、英語名のカラムにしたviewが別にあって、そっちを使うように指示が出ていたよ！
0164NAME IS NULL
垢版 |
2010/10/24(日) 19:12:43ID:???
>>162
Oracle7.2で機種依存文字を含んだマルチバイト文字でテーブル名や列名で
作ったもの(当然ダブルクォーティングなし)をOracle9.2に移行したら、
ダブルクォーティングしないとエラーになってとんでもない作業量になった
と泣いていた人を知っている。

胃に穴があいて1年以上休んで、結局退社したそうだ。
0165NAME IS NULL
垢版 |
2010/10/24(日) 19:27:21ID:???
何だかんだで英語のほうが無難ってことにうちの会社は行き着いてる。
そういや、日本語使ってる人はプログラム等でも変数に日本語使ってるのかな？
0166作り話乙
垢版 |
2010/10/24(日) 21:25:21ID:???
>>164
SQL のフィールド名とかをダブルクォーテーションで囲むぐらいのことで
「とんでもない作業量」になるような設計だといずれ破綻してると思うよ。
0167NAME IS NULL
垢版 |
2010/10/25(月) 03:07:07ID:???
>>164
サーバサイドなのかクライアントのアプリなのかは知らんが、その程度のことはデバックさえしっかり出来れば8割9割は自動化出来るだろ
0168NAME IS NULL
垢版 |
2010/10/26(火) 11:42:06ID:???
Oracle Directのセミナーで用意されるテキストのテーブルもマルチバイトの
テーブル名や列名をダブルクォーティングしていない。
自分の会社の看板に泥を塗っているやつらだ。

そういうのを見ていて 159 みたいに思う人が出てくるのであろう。
0169NAME IS NULL
垢版 |
2010/10/26(火) 20:13:46ID:???
アンカの付け方一つ知らないヤシが何言っても説得力ゼロだな
0170NAME IS NULL
垢版 |
2010/10/27(水) 00:06:39ID:???
どうせなんかのセミナーとかで聞きかじって得意になって >>151 を書い
たら馬鹿にされたので、顔真っ赤になってるだけだろ。

こんなことで「リスク」とか言っちゃってるのがほほえましいじゃないか。
0171NAME IS NULL
垢版 |
2010/10/28(木) 11:28:35ID:???
>>166
Oracle7.3で機種依存文字を大量に含んだ表名や列名があるシステムで
テーブル数が1,000以上ってのをOracle10.2.0へ移行するのを助っ人で
手伝ったことがある。

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

基本給より残業代の方が多かったが、マルチバイトで設計したテーブル
のシステムの依頼はすべて断っている。
0172NAME IS NULL
垢版 |
2010/10/28(木) 11:51:35ID:???
>>171
何でその程度のことを予知できなかったのかな。

0173NAME IS NULL
垢版 |
2010/10/28(木) 12:12:19ID:???
機種依存文字を大量に含んだテーブル名、フィールド名を
ダブルクォーティングすることには、誰も反対していないと
思うけど。
0174NAME IS NULL
垢版 |
2010/10/28(木) 14:34:59ID:???
>>170
マルチバイトでテーブル設計するのが格好良いと思っているのかな？
それもダブルクォートで囲まないで。

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

みっともない仕事はしないように。
0175NAME IS NULL
垢版 |
2010/10/28(木) 21:31:04ID:???
>>171
誰が作業工数見積もったか知らんが（まさかおまえじゃないよな？ｗ）、移行元のDBでマルチバイトが使われているにもかかわらず
ダブルクォーティング作業を工数に入れないのはただの凡ミスだろうが。基本中の基本だろ、そんなこと。

挙句逆切れとか、そんな業者、客の方が願い下げだろjk
0176NAME IS NULL
垢版 |
2010/10/28(木) 22:02:18ID:???
どうせ >>164=>>171 だろうけど...

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

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

うそつくにしても素人杉。
0177NAME IS NULL
垢版 |
2010/10/29(金) 12:03:41ID:???
お客様の要望なら全角文字だろうが機種依存文字だろうが、使えば。
後で何が起ころうとそういう要求を出した側の責任。

1995年になってもわが社では年は2桁で持つことにしています、って
豪語していた会社もあったし。
0178NAME IS NULL
垢版 |
2010/10/29(金) 15:53:43ID:???
ダブルクォーツで囲むか囲まないかはたいした問題ではない。つまり、
だから日本語を採用するかしないかと言うような影響のでる事ではない。
読み易さ、使いやすさの問題。
日本語をフィールド名に採用するか、どうかは、データモデルと
プログラミング、オペレーション時の認識に関わる問題でずっと深刻。
一般論としては、フィールドとは集合の事だから、集合の要素の大半が
全角文字で表された場合は、フィールド名(属性)も自ずと全角文字が
使われることが予想される。それが自然ということ。
0179NAME IS NULL
垢版 |
2010/10/30(土) 11:42:04ID:???
> フィールドとは集合の事だから

珍説はチラシの裏にでも書いとけ。
0180NAME IS NULL
垢版 |
2010/10/30(土) 14:50:12ID:???
まとめると
日本語派→わかりやすさ重視
英数字派→互換性重視
ってことだよな。
結局、戦争に勝ったのにろくに英語教育しなかったアメリカが悪い。
占領した朝鮮にちゃんと日本語教育してやった日本はもっと評価されるべき。
0181NAME IS NULL
垢版 |
2010/10/30(土) 21:26:30ID:???
>>178
設計段階では、データベースってのは確かに集合でしかないわけだからあんたの言っていることは正しい。
ただし、実装段階でハードやらソフトの制約を受けた時点で、集合論のそのままを表現できるわけじゃないことぐらい分かるだろjk
0182>>178=>>181
垢版 |
2010/10/30(土) 22:45:24ID:???
>>181
> データベースってのは確かに集合でしかない

珍説はチラシの裏にでも書いとけ。
0183NAME IS NULL
垢版 |
2010/10/31(日) 00:19:43ID:???
>>182
おいおい、人を勝手に自作自演にするなよｗ
T字形でもやれば、データモデルが集合論であることは良く分かる。

ただ、それをそのままデータ設計に持ち込むのは論外だと言っているまでで。
集合論からのアプローチは珍説でもなんでもない。
0184NAME IS NULL
垢版 |
2010/10/31(日) 09:26:47ID:???
フィールド名とデータの中身の区別もついてないのか...。

さすがに珍説を堂々と書ける椰子は頭の構造が違うな。
0185NAME IS NULL
垢版 |
2010/10/31(日) 11:55:41ID:???
中身に日本語が使えて、名前に制約があるのはソフトの問題。
本質的な話じゃない
0186珍説以前だったな
垢版 |
2010/10/31(日) 13:18:35ID:???
> 中身に日本語が使えて

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

スレタイすら読めてないのか...。
0187NAME IS NULL
垢版 |
2010/10/31(日) 13:25:01ID:???
>>186
名前に日本語の制約がないなら、それでいいんじゃないの？
0188NAME IS NULL
垢版 |
2010/10/31(日) 14:04:17ID:???
>>186
文句が言いたいばかりに、自分の言っていることが支離滅裂になっていることも気がつかない？
0189NAME IS NULL
垢版 |
2010/10/31(日) 18:08:14ID:???
スレ違いを指摘されて逆切れ？
0190NAME IS NULL
垢版 |
2010/10/31(日) 18:35:38ID:???
論理的な話もできずに、派生した話をスレ違いというだけの低脳がなにを言うｗ
0191NAME IS NULL
垢版 |
2010/10/31(日) 20:49:45ID:???
最近は、唐突に違う話題を垂れ流すのを「派生」とか言うのか？

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

とか言われれば満足かな (ゲラ
0192NAME IS NULL
垢版 |
2010/10/31(日) 22:53:00ID:???
例えば、全角文字を含むフィールド名はダブルクォーティングしなくては
ならないような愚劣なRDBMSをどれだけ速やかに他のシステムに乗り換える
ことができるかが問われているということだ。
0193NAME IS NULL
垢版 |
2010/11/01(月) 22:08:37ID:???
ダブルクォートするよりシステムを乗り換える方が簡単なのか？
0194NAME IS NULL
垢版 |
2010/11/02(火) 02:58:00ID:???
それは場合によるけど、リプレースする有力な根拠になるということでしょう。
0195NAME IS NULL
垢版 |
2010/11/02(火) 08:07:17ID:???
2バイト項目名がダブルクォートされていないので、リプレースしましょうと提案するのか？ありえないだろｗ
2バイトOK（動作保障的に）なSQL Serverに乗り換えるとかそういうことか？

異なるRDBMSに載せかえるくらいなら、コスト的に素直にダブルクォーティングするか、DBの改修（2バイト名の1バイト化）しかありえん。
0197NAME IS NULL
垢版 |
2010/11/02(火) 09:18:17ID:???
愚劣で未来のない仕様のシステムは次回の選定で外されるということですねw
0198NAME IS NULL
垢版 |
2010/11/02(火) 22:44:53ID:???
その前にそんな提案をするお前が次回の選定ではずされるだろ
0199NAME IS NULL
垢版 |
2010/11/02(火) 23:32:05ID:???
クォートされたマルチバイト文字は通るが、されていなければ問題があるかもしれない
なんてパーサーは、一目見ただけで食欲をなくすようなすごいソースなんだろうな。
0200NAME IS NULL
垢版 |
2010/11/03(水) 04:40:14ID:???
OLracleのバージョンアップでCHARACTERSETをJA16SJISからAL32UTF8に変えたら
テーブル名、列名、ストアドプログラム名など30バイトの制限を超えたユーザー
があって、笑えた。
新着レスの表示
レスを投稿する