Oracle® 非公式 SQL, PL/SQL & DBA's リファレンス

アプリケーション設計と開発時のガイドライン

命名規約(ネーミングルール)について テーブル名、カラムの名前

オブジェクト名、カラム名は英語だったりローマ字だったり, その混在だったりして精神衛生上悪いことが非常多い。
そこでいくつかのルールを設けて運用すれば、かなり改善することが予想される。
⇒ ネーミングルール

複数インスタンスか 複数スキーマか の選択

一般的な業務システムの場合は 1 ホスト、1 インスタンス、1 業務システム で運用する。
コスト、ライセンス等で制約がある場合には、1 インスタンス、複数業務(複数スキーマ)にし、キャッシュを独立させたい場合には、マルチブロックサイズで運用するなども考慮する。
1 ホストに複数のインスタンスを起動しても、まだまだ十分なメモリを確保できる場合には、1 ホスト、複数インスタンス運用も十分に考えられる。

テーブルの物理設計

データブロックサイズの選定

使用するキャラクタセット

データベースのキャラクタセットはサーバーOSのキャラクタセットを使用する。(※)

キャラクタセットをクライアントと同一にすると TTC(Two Task Common レイヤ) がコードの自動変換を行わないため*1に処理が速くなる、しかし、一度に大量のデータのI/Oを行うのは主にサーバー側のバッチ処理プログラムであり、この時にコード変換を行うのは都合が悪い。
キャラクタセットの選定は小さなトランザクション処理ではなく、大量データの高速処理を要求されるプログラムのキャラクタに合わせる方が総合的には良い。

Windowsは内部処理はUnicode、表示はShift-JISを使用しているので、Windowsのミドルウェアではキャラクタセットを問わずコード変換は常に行われていると考えられる。
(Windowsクライアント向け = SJIS と決定するのは×。格納効率なども含め、総合的に判断する)

(※) 最大のクライアントである Windows Vista の登場によって Oracle もキャラクタセットの淘汰があるのでしょうか？
日本語のキャラクタセットにおいて UNICODE(AL32UTF8) の選択が今後デファクトスタンダードとなる可能性があるので JIS X 0213:2004 / 第3・4水準漢字 の利用頻度とユーザー要件に対してどのような影響がどの程度波及してくるのかも注視しておく必要がありそうな微妙な時期です。

参考: 文字コード・キャラクタセット

使用するキャラクタセット 全角チルダ(〜)の問題

Windows環境のミドルウェアにおいて「〜」が文字化けする問題。
これは、Microsoftが誤って? Shift-JISの波ダッシュ(0x8160)をUnicode 波ダッシュ(U+301C:Wave dash)ではなく、全角チルダ(U+FF5E:Fullwidth Tilde)に割り当てしまっている事が原因らしい。
MS の「これがうちのデファクトスタンダード(仕様)です」という類であり、素直に 〜TILDE を使用する。 *2

キャラクタセットには JA16SJISTILDE / JA16EUCTILDE を使用する。(R9.0.1.4〜)
サーバーのデータベースキャラクタセットとともにクライアントのキャラクタセット(NLS_LANG 環境変数)も環境に適した JA16{SJIS|EUC}TILDE を設定する。

JA16SJISTILDE / JA16EUCTILDE が使用できる環境(オラクルクライアントソフト含む R9.0.1.4〜)では、JA16SJIS / JA16EUCは使わないようにする。

DBCA のデフォルト設定は 〜TILDE ではない。データベースの作成時には気をつける。

• 関連事項

  MS932 (Microsoft code page 932) Windows-31J
  JDBC 8.1.7上でのNLS環境におけるキャラクタの整合性の問題について(Oracle Technology Network Japan '01/04/06)

半角カタカナの使用について

半角カタカナの使用は ShiftJIS では 1 バイト、EUC-JP では 2 バイトになる。 そのため、システムを EUC 環境に移植するときにデータを格納できないことによる SQL エラーやインポート、エクスポートユーティティのエラーが発生するという場面に稀に遭遇する。(影響範囲を調査するのに無駄な工数を要することさえある。)

それに加えてシステム上において、半角カタカナの使用はインデックスへのアクセスやソートを行うときに問題がある(主に濁点や半濁点)。
その問題を回避してもシステムに無駄が発生するため、新規のプロジェクトでは使用を控えるように努力する。

現在でも EDI で使用している住所、会社名、支店名、氏名などに多くの半角カタカナが多く使用されているが、 WEBアプリケーションで運用している(しようとしている)場合には誤変換の危険性もあり全角で取り扱うように変更した方がよい。(金融系はあと半世紀は無理そうなので素直にあきらめる)
既存環境で利用している場合には ETL の層で 半角カタカナから全角へと変換 を行って新規システムへ投入するようにできないか検討してみる。

ユーザー

• オブジェクトの所有者と実行者は分ける。

  定義者と利用者が同一であった場合、性善説でおかしなことをしなくても間違って変更しても気づかない、削除しても気づかない、などを防止する。⇒ シノニム

• デフォルトでインストールされるユーザーはパスワードを期限切れ(ロック)にする。
  

• 関連事項

  自動作成されるユーザ一覧
  権限に関するセキュリティ

デフォルト制約

• テーブルのデフォルト制約をとりあえず的に乱用するのは避ける。

  例えば全フィールドにデフォルト制約を設置すると、 PL/SQLでレコード変数を使用すると変数の初期化の仮定で全フィールドにデフォルト値が設定される。
  (何度も呼ばれるプロシージャや使用しないフィールドが多い場合には、かなり無駄)

外部キー制約にはインデックスの設置を行う(外部キー制約で共有ロック)

⇒ ガイドライン：外部キー制約にはインデックスの設置を行う(外部キー制約で共有ロック)

SQL, PL/SQL

INSER文での項目名を完全に省略した形式の使用は禁止(ソースが残らないような場合は別)
分かりにくいことに加え、レイアウト変更がされた場合にフィールドに違うフィールドへのデータを設定する危険性がある。

外部結合演算子(+) の使用の停止

外部結合 を行なう (+) 演算子には、いくつかの制限事項があるため、それに該当する場合は FROM 句での結合を使用する。
(+) 演算子は、雲行きが怪しい。 最新の Oracle を新規導入するような、しがらみの無い完全な新規のプロジェクトの場合では使用しないことが望ましいと思われる。
(現在は過渡期であり Oracle が推奨しているとはいえ、不具合などの事情から既存の環境での開発の場合、相当に慎重に判断しないと面倒なことになる可能性がある。)

Oracle の制限事項

⇒ Oracle 性能限界

---