実務でハマる！OracleとPostgreSQLの違いとSQLの注意点

これまでの記事で、データベースとRDBMSの基礎、そして基本的なSQLの書き方について解説してきました。

基礎を学んでいざ実務で社内システムを見てみると、「学んだ通りに書いたのにエラーになる」「システムによってSQLの書き方が違う？」と戸惑う場面が必ず出てきます。

実は、RDBMS（データベース製品）にはそれぞれ「方言」や「クセ」が存在します。今回は、情シスの実務でよく遭遇する「Oracle」と「PostgreSQL」の違いを中心に、RDBMSごとの注意点を解説します！

昔の書き方に注意！「カンマ区切り」のテーブル結合

社内の古いシステムのSQLを見ていると、以下のような結合条件を見かけることがあります。

SQL

-- 古い書き方（暗黙の結合）
SELECT A.emp_name, B.dept_name
FROM employees A, departments B
WHERE A.dept_id = B.dept_id;

-- 古い書き方（暗黙の結合）
SELECT A.emp_name, B.dept_name
FROM employees A, departments B
WHERE A.dept_id = B.dept_id;

実はこれ、古いOracleのシステムなどで非常によく見る書き方です。「Oracle独自の書き方」と誤解されることも多いのですが、正確には「SQL89」という古い時代の標準規格です（PostgreSQLなどでも動くことは動きます）。

しかし、現代の開発においては推奨されません。理由は、結合条件（A.dept_id = B.dept_id）と、単なる絞り込み条件（例：A.age >= 30）が、すべて同じ WHERE 句に混ざってしまい、非常に読みづらくなるからです。また、条件を書き忘れると膨大なデータ同士が掛け合わされる大事故（クロスジョイン）が起きます。

現在は、前回学んだ「SQL92」という規格の JOIN を使うのが絶対のルールです。

SQL

-- 現在の推奨（明示的な結合）
SELECT A.emp_name, B.dept_name
FROM employees A
INNER JOIN departments B 
    ON A.dept_id = B.dept_id;

-- 現在の推奨（明示的な結合）
SELECT A.emp_name, B.dept_name
FROM employees A
INNER JOIN departments B 
    ON A.dept_id = B.dept_id;

古いSQLを見つけたら、「昔の書き方だな」と理解しつつ、自分が書くときは必ず JOIN を使いましょう。

「NULL」と「空文字(”)」は同じ？違う？

実務で最もハマりやすい罠が、「データが空っぽ」の状態の扱いです。実は、OracleとPostgreSQLでは、文字列における「NULL（データが存在しない）」と「空文字（文字数ゼロの文字列 ''）」の解釈が異なります。

Oracleの場合 文字列項目において、空文字（''）は自動的に NULL として扱われます。そのため、WHERE 項目 = '' と書いてもデータはヒットしません（NULL は = で比較できず、IS NULL を使う必要がある）。
PostgreSQL（および標準SQL）の場合 「NULL」と「空文字（''）」は完全に別物として区別されます。未入力のデータを探す際、システムが「NULL」で保存しているのか、「空文字」で保存しているのかを正確に意識して条件（IS NULL なのか ='' なのか）を書き分ける必要があります。

Oracleの常識でPostgreSQLを操作すると、「データがあるはずなのに抽出できない！」というトラブルになりがちなので注意が必要です。

エラーチェックの厳密さと「短絡評価」の違い

システムからパラメータ（変数）を渡してSQLを実行する際にも、RDBMSの性格が出ます。例えば、以下のように「パラメータ（:A）がNULLなら全件検索、値が入っていればその値で検索する」というテクニックがあります。

SQL

WHERE (:A IS NULL OR target_column = :A)

WHERE (:A IS NULL OR target_column = :A)

このとき、PostgreSQLで実行すると構文エラーや型エラーで弾かれることがあります。

これは主に2つの理由があります。

PostgreSQLの厳密な型チェック PostgreSQLはSQLを実行する前の構文・型チェックが非常に厳格です。:A に何型が入るのか特定できないと、実行前にエラーにしてしまいます。
OR条件の評価順序（短絡評価） プログラミング言語の多くは「OR の前方がTRUEなら、後方は実行・評価しない（短絡評価）」という動きをしますが、SQLの標準規格ではこの評価順序を保証していません。 Oracleのオプティマイザ（SQLをどう実行するか考える脳みそ）は柔軟によしなに処理してくれることが多いですが、PostgreSQLでは後方の target_column = :A も評価しようとして型エラーなどに引っかかるケースがあります。

RDBMSによって「どこまで曖昧な記述を許してくれるか」が異なるため、システム移行などの際は特に注意が必要です。

ツールや言語との「相性」を考慮しよう

ここまで見てきたように、RDBMSは「どれも同じようにSQLが動く」わけではありません。

そのため、システムを構築する際は、使用するプログラミング言語、フレームワーク、BIツールと、RDBMSの相性を考えることが非常に重要です。

特定のRDBMS特有の機能（方言）に依存しすぎると、将来「有償のOracleから、無償のPostgreSQLに乗り換えたい」となったときに、莫大な修正コストが発生します。システムの要件や、連携するツールの得意・不得意を見極めて、適切なデータベースを選ぶのが情シスの腕の見せ所です。

まとめ

データベース製品には、それぞれの歴史と設計思想による「方言」があります。エラーが出たときは「自分のSQLが間違っている」だけでなく、「このRDBMSの仕様ではどう解釈されるのか？」という視点を持つと、解決への糸口が掴みやすくなります。

焦らず、公式ドキュメントやマニュアルを引きながら、システムと向き合っていきましょう！