テーブル、フィールド名は日本語がよいか、アルファベットがよいか

[アーティクル]
12/25/2018

質問

_{2018年12月25日火曜日 7:05 | 1 票}

これまでAccessでリンクテーブルを使用してバックエンドとフロントエンドに分けて社内のデータベースを運用してきました。

先日、使用する人数も増えたのでバックエンドをSQL Serverへの移行し、Accessのフロントエンドから操作を行うシステムに変更しました。

これまでテーブル、フィールド名はすべて日本語で作っていましたが、SQL Serverへ変更したことを機に、これから開発する際の新しいテーブル・フィールド名をアルファベットにするか悩んでおります。（開発済みのテーブルは日本語のままで行こうかと思っています。）

この話題に関しては昔から賛否両論があり、宗教的な部分もあると理解した上でご意見をお聞きしたいです。

私なりに考えている

日本語のメリット

・漢字を使えば短くできる

・なじみのある専門用語を使用できるため日付をまたいで作成した場合でもフィールド名を統一させやすい(設計指示書を作れば良いのですが…）

・これまで開発したものが日本語なので関係性が把握しやすい。

アルファベットのメリット

・日本語を使用していることによるエラーを回避できる(今のところなさそうですが、ネットを確認していると細かな制約もあるようなことがあったので記載しました）

・今後別のフロンドエンドを使用した場合でもそのまま使用できる？？（特別予定はないのですが、、、）

今後の汎用性を考えるとアルファベットを使用した方が良い気もしますが、これまでのDBとの統一性や勉強しながらの開発のため日本語のフィールド名の方が運用しやすいのも事実です。

ソフトは今のところ自分たちだけ、開発も私;1名の二人で行っています。（開発しているのはほとんど私一人ですが）

ご教授の程宜しくお願いいたします。

すべての返信 (8)

_{2018年12月25日火曜日 8:26 ✅回答済み}

データベースが日本語をサポートしていますので、フィールド名を日本語にしない理由はないと思います。
将来的なフロントエンドは予測できませんが、まず問題が発生することは無いと思います。
それよりも日本語を用いることの可読性のメリットが大きすぎると思います。
確かに昔の汎用機の頃は日本語が使えず、私もしばらくはSQL Serverで日本語を用いていませんでしたが、今となっては日本語でないのは考えられません。
もし、日本語がわかる人達だけで開発するのであれば、日本語を使用することを強くお勧めします。これはプログラムにおける変数名も同様です。
確かにいろいろな考え方があるかとは思いますが、SQL ServerやOracleを始めとして、フィールド名が日本語でないシステムには近年出会ったことがありません。
むりやりおかしな英語にしたり、ローマ字にしたりするよりも、日本語で表記することを優先した方が良いと思います。ただ、英語表記がわかりやすいところは英語表記で良いと思います。無理に全て必ず日本語で無くても良いと思います。

★良い回答には質問者は回答済みマークを、閲覧者は投票を！

_{2018年12月25日火曜日 9:15 ✅回答済み | 3 票}

SQL Server の世界だけであれば話は別かもしれませんが、それをソースとしたアプリケーションも考えるのであれば、自分はすべて ASCII 文字に限定派です。

今も将来も日本語の読み書きができる者しか開発・保守には 100% 絶対に携わることがないとしてもです。

C# や VB.NET でも、変数、メソッド、プロパティなどの識別子名に、見易さや保守性を考えて日本語を使うという話を時々聞きますが、言語仕様上許されているからと言って安易に使うと思わぬ副作用がありそうです。

具体的な例は以下の記事を見てください。

識別子名に日本語
http://surferonwww.info/BlogEngine/post/2015/03/17/japanese-name-for-identifiers-such-as-variables-methods-and-properties.aspx

それ以外にも、例えば Visual Studio のウィザードで型付 DataSet / DataTable ; TableAdapter や ADO.NET Entity Data Model を作るような場合、SQL Server のテーブル名やフィールド名が日本語だったりすると、生成されたソースは、自分に言わせてもらえれば、使い物にならないレベルだと思っています。

_{2018年12月26日水曜日 9:18 ✅回答済み | 1 票}

自分のところだと、対 SQL Server は PascalCase 、対 Oracle は SNAKE_CASE 表記が多いですが、命名は英語ではなく日本語ベースにしています。文字種が「英数字のみ」あるいは「数字・大文字アルファベット・アンダーバー」というだけで。

※ローマ字も日本語の表現方法の一つですよね。

その一方、個人的にはマルチバイト文字を使うことは嫌いではないですし、実際に使うこともあります。ただ、最近の EMOJI ブームに乗って、サロゲートペアな項目名を使われたりするのも困るので💦、プロジェクト要件としては使う文字種を Shift_JIS の範囲に限定させるようにしています。あるいはせめて UCS-2 までですね。(たとえばコマンドライン系のツールだと ANSI ベースの方が都合が良かったりするなどの理由から）

・日本語を使用していることによるエラーを回避できる(今のところなさそうですが、ネットを確認していると細かな制約もあるようなことがあったので記載しました）

不具合や制限などで、マルチバイト文字が使えないことはありますが、そこは使い分けかと思います。

参考までに、幾つかの障害事例を載せておきます。しかしこれらはエスケープ表記で対応できる可能性がありますし、バージョンアップで改善されることもあります。（逆に、バージョンアップによって問題が生じたケースもあるのですが）

問題点が事前に分かっている場合には、危険性のある文字を避けるようにするとか、回避可能なエスケープ表記を使うとか、非対応ソフトから対応ソフトに切り替えるなどで対処できるかと思います。あるいは、その判断を個別に行う手間をかけるぐらいなら、最初からアルファベットのみに制限するというのもまた選択肢の一つかと。

こういうのはデータベース項目に限った話では無いかもしれません。

たとえばファイル名。普段、ドキュメントフォルダー内にある Excel ファイル名に漢字が含まれていることは珍しくないですが、その一方で、処理系によっては「5C 問題」「パス中の ; や #」「Shift_JISに無い Unicode 文字」で障害を起こすケースがあるわけです。でも、そうしたファイル名であっても「Unicode パスに対応したアプリ」では問題無く読み書きできるものはありますし、非対応のアプリでも、そうした文字を避けて使えば、アルファベットのみに制限せずとも、漢字を含むファイル名を扱えますね。

_{2018年12月26日水曜日 1:01}

それ以外にも、例えば Visual Studio のウィザードで型付 DataSet / DataTable ; TableAdapter や ADO.NET Entity Data Model を作るような場合、SQL Server のテーブル名やフィールド名が日本語だったりすると、生成されたソースは、自分に言わせてもらえれば、使い物にならないレベルだと思っています。

ウィザードで型付 DataSet / DataTable ; TableAdapterを生成した場合、使い物にならないレベルだとおっしゃられていますが、具体的にどのようなことなのでしょうか？　特に私は日本語を使用していて困ったことは一度もないのですが、今後、ハマるポイントがあるかもしれませんので、後学のために教えていただけないでしょうか？　また、質問者さんも日本語を採用するかどうかを決定する上で、どのように使い物にならないかが私と同様に知りたいのではないか思います。
日本語対応がうまくできていないところがあれば、フィードバックしなければならないと考えています。

ADO.NET Entity Data Model に関しては、私は使わない派なのでこちらに関しては経験不足でわかりません。

★良い回答には質問者は回答済みマークを、閲覧者は投票を！

_{2018年12月26日水曜日 3:06 | 2 票}

> ウィザードで型付 DataSet / DataTable ; TableAdapterを生成した場合、使い物にならないレベルだとおっしゃられていますが、具体的にどのようなことなのでしょうか？

使い物にならないレベルというのは、あくまで「自分に言わせてもらえれば」という条件付きなのですが・・・

でも、SQL Server のテーブル名、フィールド名に日本語を使うと以下のようなプロパティ、メソッドが自動生成されると思いますが、普通に考えて、日本語と英語がゴッチャになっているのは見やすくも使いやすくもないと思います。

public 製品DataTable 製品 {
    // ・・・
}

public global::System.Data.DataColumn 製品IDColumn {
    // ・・・
}

public 製品Row Add製品Row(string 製品名,  ... ) {
    // ・・・
}

ただ、「これで問題ない、ゴッチャになるデメリットより日本語で読みやすいメリットの方が大きい」と言われる方には、自分はご自由にどうぞと言うしかないですが。

_{2018年12月26日水曜日 5:51}

ありがとうございます。
私は慣れたのか特に違和感がありませんが、これは好みの問題だと思いますので、人それぞれということですね。

また、私は業務アプリを作成することが多いのですが、そうすると英語にするには馴染みのない日本語が多く出てくるのも、私が日本語を好む一因かもしれません。
会計アプリの設計になると支払伝票テーブルや支払伝票ID、振替伝票テーブルや振替伝票ID、消費税率などの方が、私にはわかりやすいです。営業系も同じで、契約、契約種別、継続区分などもそうです。

また、業界用語が入る場合には日本語の方がわかりやすいと思います。業界用語なんてそもそもが造語なので、それを無理やり英語にするとわけがわからなくなります。例えば放送業界では枠時刻という単語がありますが、これも一般的ではないので英語にするのが難しく、漢字が使えない汎用機ではWTIMEのように定義していました。こういう名前はそれを覚えるという労力が発生しますし、初めてみた人はそれだけでは何を表しているフィールドなのかよくわからないでしょう。

日本語を使うか使わないかは、どのようなアプリを開発するのかにもよるのだと思いました。

★良い回答には質問者は回答済みマークを、閲覧者は投票を！

_{2018年12月26日水曜日 7:11}

いろいろなご意見ありがとうございます。

どちらの意見も大変参考になりました。

まず結論からお伝えすると、今回のアプリは日本語のテーブル・フィールド名を採用し続けようと思います。

trapemiya様のご意見の通り、

・私は英語に詳しくないため専門用語を馴染みのない英語にすると後で修正しようとしたときにそのフィールドが何だったのか確認する時間がかかる。

・作るときにprocessをprcssやprcと省略したり、しなかったりと統一性が取りづらい

ことが過去にもあったため、日本語名を採用することにしました。

またこれまでに作ったテーブルをすべてローマ字に変換し、フロントエンドもすべて変更するというのは現実的ではなくフィールドの関係性も相関がとりやすいので、このまま日本語で進めようと思います。

ただSuferOnWww様の言う通り日本語と英語が入り乱れると分かりづらく、またプログラムする際にも半角と全角をこまめに切り替えるのは面倒なので、半角で統一した方が良いという意見にはすごく納得できます。

上記の理由から今回のアプリは日本語で統一しようと思いますが、次回最初からアプリを作る際はまた悩みそうです。

御二方のご意見は大変参考になりました。本当にありがとうございました。

_{2018年12月27日木曜日 5:34}

魔界の仮面弁士様ありがとうございます。

確かに英数字を使うから英語を使わなければならないということはないですね。ついつい英数字を使うと英語表記をしないとかっこ悪い感覚になってしまっていましたが、英語や日本語が混在して分からなくなるくらいなら、日本語を英数字で表記するというルールにしてしまえば統一性も取れるし、開発しやすくなるかもしれませんね。

またPascalCase, SNAKE_CASEという単語は知らなかったので勉強になりました。これまで本やインターネット上のサンプルを見て知らず知らずのうちにまねしていたのですが、混在していたのでこれを機に統一していこうかと思います。

大変勉強になりました。

次の方法で共有

テーブル、フィールド名は日本語がよいか、アルファベットがよいか

質問

すべての返信 (8)

その他のリソース