スキーマ・オブジェクト名(テーブル名、カラム名など)に日本語名を使うことは…
一部のシステムではテーブル名などに日本語を使用するという選択肢も考慮できる環境になってきているようです。
しかし、Oracle データベースを使用するという前提において現在でも、設計以後の多くのフェーズにおいて重要な項目のデメリットが多く、影響度が強いと思われます。
ここでは日本語名の使用はお勧めしない立場から話を進めていきます。しかし、要件定義・設計から開発・運用、次期システム移行までのライフサイクルにおける全体フェーズにおいて日本語で書くことのメリットから該当するデメリットを引き算してから慎重に判断してください。
注意 ここに書いてあるルールは、独自に決めたマイルールです。Oracle に関連ドキュメントがある、あるいは書籍で紹介されているなどのように、一般的に定着している、知れ渡っている類のものではありません。よって人に強要するような正当性もありません。
( 何より、このドキュメントに対して他人への説得材料や根拠としてのバリューを求めてはいけません。 )
日本語をスキーマ名、カラム名に使用した場合
日本語のオブジェクト名は、コーディングスピードが著しく遅くなるため開発コストが高くつく。
エンドユーザー向けに一部のテーブルのレイアウトを公開する必要がある場合、ビュー を個別に作成することで対応する。(見せたくないカラムを伏せることもできる) 。すべてのテーブルを日本語名として公開する必要がある場合には…判断が難しい。
ただ、クライアントの特別な要望がない限り、カラム名の名付けに時間的余裕がない場合でも、すべてローマ字表記にしてでも、日本語のオブジェクト名は避けたいところである。
日本語使用を控えたい大きな理由として (1)二重引用符(")の徹底、(2)大文字小文字の厳格な評価、(3)多国語サポートによる文字化け、(4)文字コードの長さに違いによる移植性の低下などが思いつく。特に (4) は将来、致命的な選択ミスとなる可能もあるので慎重に検討する。
- 二重引用符(")の徹底
Oracle8i (R8.1.6) 以降、日本語オブジェクト名には必ず二重引用符(")で囲まれた引用識別子を使用しなければならない仕様になっている。
二重引用符(")で囲まれてない日本語の非引用識別子であっても問題なく動作はしていることがあり、使用しても問題ないという誤解が多い。これは非常に危険である。仮に問題が発生しても独自に解決しなければならない=正式なサポートを受けることができないシステムになってしまう可能性がある。
また特定の文字コードで不具合が発生したり、ミドルウェアによってはサポートされていなかったり、(新旧に関係なく)バージョンによって動作しなくなることがある。
- 大文字小文字の厳格な評価
引用識別子は英字の大文字小文字の違いも評価されるため、非引用識別子とは異なりカラム名は大文字小文字も厳密に記述しなければエラーとなる点にも注意が必要である。
- 多国語サポートによる文字化け
Oracle のようにデータベースキャラクタセットを複数使い分けることが考えられるシステムの場合には、
引用識別子であっても日本語オブジェクト名の作成スクリプトなどを NLS_LANG の異なる環境で実行すると文字化けしたオブジェクトが作成される。投入した当人以外はテーブル名を判定することが非常に困難となる。そのため複数システムが乗り入れているような運用において管理面からも都合が悪いことが多い。担当者が DDL を手打ちしていて履歴がないような場合は後始末に一苦労することになる。
- 移植性の低下
データベースのキャラクタセットを JA16SJIS (JA16EUC) で作成した場合では日本語は 1 文字が 2(3) バイト AL32UTF8 でデータベースを作成すると 1 文字が 3バイトになる。
Oracle 12c R1 以前の環境では Shift-JIS で作成したシステムを UTF8 に移植する場合、テーブル名が最大 20 文字から 10 文字に制限される。(※1)
そのためテーブルが作成できず UTF8 の環境ではシステムの構築ができません。という事態になる可能性もある。 参考: 文字コード・キャラクタセット
コーディング時のコスト+メンテナンスコスト+バグ以外の心配事>ユーザー向けのビュー・メンテナンス(※2)
(※1) Oracle 12c R2 から 識別子に使用できる文字列長が 30 バイトから 128 バイトに拡張されている。
(※2) コーディングルールが周知徹底されていない場合や経験の浅い開発者がいる場合にも、引用識別子関するトラブルに悩まされることもない。特に開発作業が終了して運用テスト時に引用識別子を使用していないことが発覚すると、すべてのプログラムの SQL を再確認しなければならず、テストし直し・・・検収作業が恐ろしいほど大変になる可能性がある。
日本語の使用が公式に許可されていないもの(禁止)
- ディレクトリ名
- ファイル名
Windows の場合に利用者の名前が日本語の場合にはインストールもできない可能性あり
- データファイル名
- 制御ファイル名
- ログファイル名
- 初期化パラメータファイル名
- RMAN ファイル名
- データベース名
- データベースリンク名
- インスタンス名
- ローバックセグメント名
- 表領域名
日本語プログラミング?
(注意) マニュアルにはマルチバイト・キャラクタセットで記述したプログラムをコンパイルしたり実行することについて、
どのようになるかが書かれていません。よって PL/SQL では日本語は使用した結果どのようになっても知りません。
プロシージャ名については日本語を使うことはできると記述されている*1のですが、サードパーティのツール側で正しく動作しないものがあるので日本語にするのはやめておいた方がよいでしょう。
CREATE OR REPLACE PROCEDURE RIVUS.NIPPON_GO
IS
"この問題を解いてください" VARCHAR2(80) := '簡単な算数です';
"答えは 300 になります" VARCHAR2(80) := '300 でも 3000 でもありません';
"100" NUMBER;
"200" NUMBER;
FUNCTION "加算器"("1000" IN NUMBER, "2000" IN NUMBER)
RETURN VARCHAR2
IS
"3000" NUMBER;
BEGIN
"3000" := "1000" + "2000";
RETURN "1000" || '+' || "2000" || '=' || "3000" || ' ですよね';
END;
BEGIN
"100" := 1;
"200" := 2;
DBMS_OUTPUT.PUT_LINE("この問題を解いてください");
DBMS_OUTPUT.PUT_LINE("加算器"("100","200"));
DBMS_OUTPUT.PUT_LINE("答えは 300 になります");
END;
/
--- 実行例
SQL> CALL NIPPON_GO();
簡単な算数です
1+2=3 ですよね
300 でも 3000 でもありません
コールが完了しました。
関連事項