フィールド名は日本語にするか、英語にするか
プログラミング的には、変数名と同じ感覚で英語なのかもしれないが、 英語にすると、日本語との変換データが必要になる。 ユーザーの感覚では日本語が当然わかりやすい。 特にユーザーがなんらかのUIを経て、テーブルやフィールドを 自由に作成する場合は日本語が良い? ちとスレ違いではあるが、誰か知ってたら教えて欲しい。 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 のフィールド名とかをダブルクォーテーションで囲むぐらいのことで 「とんでもない作業量」になるような設計だといずれ破綻してると思うよ。 >>164 サーバサイドなのかクライアントのアプリなのかは知らんが、その程度のことはデバックさえしっかり出来れば8割9割は自動化出来るだろ Oracle Directのセミナーで用意されるテキストのテーブルもマルチバイトの テーブル名や列名をダブルクォーティングしていない。 自分の会社の看板に泥を塗っているやつらだ。 そういうのを見ていて 159 みたいに思う人が出てくるのであろう。 アンカの付け方一つ知らないヤシが何言っても説得力ゼロだな どうせなんかのセミナーとかで聞きかじって得意になって >>151 を書い たら馬鹿にされたので、顔真っ赤になってるだけだろ。 こんなことで「リスク」とか言っちゃってるのがほほえましいじゃないか。 >>166 Oracle7.3で機種依存文字を大量に含んだ表名や列名があるシステムで テーブル数が1,000以上ってのをOracle10.2.0へ移行するのを助っ人で 手伝ったことがある。 ダブルクォーティングの作業なんか予定になかったからスケジュールの 期限に間に合わなかった。今使われているどうかもわからないプログラム も含めて、何万とあるSQLの動作確認も必要だったからメンバーを10人 補充してもらったが2ヶ月以上遅れた。 基本給より残業代の方が多かったが、マルチバイトで設計したテーブル のシステムの依頼はすべて断っている。 >>171 何でその程度のことを予知できなかったのかな。 機種依存文字を大量に含んだテーブル名、フィールド名を ダブルクォーティングすることには、誰も反対していないと 思うけど。 >>170 マルチバイトでテーブル設計するのが格好良いと思っているのかな? それもダブルクォートで囲まないで。 将来、会社に多大な出費を強いるかもしれないというリスクを負うこと がわからないのか? みっともない仕事はしないように。 >>171 誰が作業工数見積もったか知らんが(まさかおまえじゃないよな?w)、移行元のDBでマルチバイトが使われているにもかかわらず ダブルクォーティング作業を工数に入れないのはただの凡ミスだろうが。基本中の基本だろ、そんなこと。 挙句逆切れとか、そんな業者、客の方が願い下げだろjk どうせ >>164 =>>171 だろうけど... > 何万とあるSQLの動作確認も必要だったから Oracle 7.3 → Oracle 10i なら、動作確認はもともと必要だろ。 うそつくにしても素人杉。 お客様の要望なら全角文字だろうが機種依存文字だろうが、使えば。 後で何が起ころうとそういう要求を出した側の責任。 1995年になってもわが社では年は2桁で持つことにしています、って 豪語していた会社もあったし。 ダブルクォーツで囲むか囲まないかはたいした問題ではない。つまり、 だから日本語を採用するかしないかと言うような影響のでる事ではない。 読み易さ、使いやすさの問題。 日本語をフィールド名に採用するか、どうかは、データモデルと プログラミング、オペレーション時の認識に関わる問題でずっと深刻。 一般論としては、フィールドとは集合の事だから、集合の要素の大半が 全角文字で表された場合は、フィールド名(属性)も自ずと全角文字が 使われることが予想される。それが自然ということ。 > フィールドとは集合の事だから 珍説はチラシの裏にでも書いとけ。 まとめると 日本語派→わかりやすさ重視 英数字派→互換性重視 ってことだよな。 結局、戦争に勝ったのにろくに英語教育しなかったアメリカが悪い。 占領した朝鮮にちゃんと日本語教育してやった日本はもっと評価されるべき。 >>178 設計段階では、データベースってのは確かに集合でしかないわけだからあんたの言っていることは正しい。 ただし、実装段階でハードやらソフトの制約を受けた時点で、集合論のそのままを表現できるわけじゃないことぐらい分かるだろjk >>181 > データベースってのは確かに集合でしかない 珍説はチラシの裏にでも書いとけ。 >>182 おいおい、人を勝手に自作自演にするなよw T字形でもやれば、データモデルが集合論であることは良く分かる。 ただ、それをそのままデータ設計に持ち込むのは論外だと言っているまでで。 集合論からのアプローチは珍説でもなんでもない。 フィールド名とデータの中身の区別もついてないのか...。 さすがに珍説を堂々と書ける椰子は頭の構造が違うな。 中身に日本語が使えて、名前に制約があるのはソフトの問題。 本質的な話じゃない > 中身に日本語が使えて 中身の話なんて誰もしてない。 スレタイすら読めてないのか...。 >>186 名前に日本語の制約がないなら、それでいいんじゃないの? >>186 文句が言いたいばかりに、自分の言っていることが支離滅裂になっていることも気がつかない? 論理的な話もできずに、派生した話をスレ違いというだけの低脳がなにを言うw 最近は、唐突に違う話題を垂れ流すのを「派生」とか言うのか? まあ、(リレーショナルデータベースの) データモデルが集合論に 関係しているって知ってるなんてしゅごいでちゅねぇ〜 とか言われれば満足かな (ゲラ 例えば、全角文字を含むフィールド名はダブルクォーティングしなくては ならないような愚劣なRDBMSをどれだけ速やかに他のシステムに乗り換える ことができるかが問われているということだ。 ダブルクォートするよりシステムを乗り換える方が簡単なのか? それは場合によるけど、リプレースする有力な根拠になるということでしょう。 2バイト項目名がダブルクォートされていないので、リプレースしましょうと提案するのか?ありえないだろw 2バイトOK(動作保障的に)なSQL Serverに乗り換えるとかそういうことか? 異なるRDBMSに載せかえるくらいなら、コスト的に素直にダブルクォーティングするか、DBの改修(2バイト名の1バイト化)しかありえん。 愚劣で未来のない仕様のシステムは次回の選定で外されるということですねw その前にそんな提案をするお前が次回の選定ではずされるだろ クォートされたマルチバイト文字は通るが、されていなければ問題があるかもしれない なんてパーサーは、一目見ただけで食欲をなくすようなすごいソースなんだろうな。 OLracleのバージョンアップでCHARACTERSETをJA16SJISからAL32UTF8に変えたら テーブル名、列名、ストアドプログラム名など30バイトの制限を超えたユーザー があって、笑えた。 SQL Serverなんて、キャラクターセット変えた程度でDB2との通信ができなくなったりする(ドライバがらみのバグ)んだぜ。 これが商用RDBMSとは到底思えないレベル。 こんなことでバグ取り1週間とか、正直笑えない。 SQL Server 本体ならともかく、ドライバ、しかも DB2 との通信だろ。 馬鹿ですか? >>200 >>201 笑うことでリューマチの痛みが軽減するものだとのことでございます。 >>202 SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して、それがキックにドライバで不具合、結果DB2との通信時に落ちる。 >>204 > SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して それは問題だ。 で、どのバージョンの話かな? ソースつきで、頼むよ。 >>205 ソースがあるぐらいのバグなら苦労しないだろw SQL Server 2005 Workgroup Editionだったのは覚えているが、ビルド番号や該当するキャラクタセット、 DB2のバージョンやドライバの種類なんかは当時の備忘録紐解かないと覚えてない。 そして、それは面倒くさいから勘弁してくれw > ソースがあるぐらいのバグなら苦労しないだろ はあ? データ異常が発生するようなバグなら、HotFix なり ServicePack が出てるだろ。何言ってるんだ? > それは面倒くさいから勘弁してくれw はいはい、言い訳乙。 >>207 実務で扱ってれば、公式対応されるバグなんてごく一部なことぐらい分かりそうなもんだが。 おまえ、素人だろ。 なんか状況が目に浮かぶようだw >>208 「これバグだろ!!」 サポート 「はいはいw」 ふーん、いきなり電話するんだ、サポートとやらにw 実際に仕事してる奴の台詞とは思えないなw バグだろうがこっちのミスだろうが、なにか自分らで解決できない問題が起きたら サポートに電話するけどな、うちは。 バグだという確証が得られるまでサポートに連絡しないの? 俺が知っている限りでは、当時(今もそのはずだが)SQL Serverに関する要望やバグを日本語で直接シアトルに電話でコンタクトする方法はなかったはずだが。 Visual Studio と .NETに関してはルートが存在していたが。 直接やりとりをできるサポートを知ってるなんて、MSの関係者ですか?w >>208 ああごめん、誰かさんの「脳内バグ」なら公式対応はしないだろうな (w >>212 保守契約したらMSの関係者じゃなくても「サポートと直接やり取り できる」よ。 て言うか、実務なら保守契約必須だと思うが...。 read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる