【実務・中級編】 IMPORT FOREIGN SCHEMA構文 – PostgreSQL

「ねえ、PostgreSQLで外部サーバーのデータを触らなきゃいけない時、わざわざ一文字ずつ `CREATE FOREIGN TABLE` を書いてないよね？」

もし図星なら、今日でその苦労は卒業しよう。

実務で PostgreSQL の `postgres_fdw` を使っていると、避けて通れないのが「スキーマ同期の面倒くささ」だよね。特に相手がマイクロサービス化されたデータベースだったりすると、テーブル定義が変わるたびにこっちの定義も修正しなきゃいけない。

そんな時、僕らエンジニアを救ってくれるのが `IMPORT FOREIGN SCHEMA` という強力な武器だ。今日はこれを使って、泥臭い作業をスマートに片付ける方法を伝授するよ。

—

通常、`CREATE FOREIGN TABLE` を個別に書くやり方は、定義が数個ならいい。でも、50個、100個となったらどうだい？途中で嫌になるし、何より「人間が書くコードはミスをする」という鉄則がある。

`IMPORT FOREIGN SCHEMA` を使えば、リモート側のデータベースを覗きに行って、必要なテーブル定義をローカルの PostgreSQL に自動で「ミラーリング」してくれるんだ。これを使わない手はないよね。

—

まずは前準備として、`postgres_fdw` を使える状態にして、外部サーバーへの接続設定（Server）とユーザーマッピング（User Mapping）が終わっている前提で話を進めるよ。

特定のスキーマ全体を、ローカルの `remote_data` というスキーマにインポートする例がこれだ。

— ローカル側の受け皿となるスキーマを作成
CREATE SCHEMA remote_data;

— インポート実行！
IMPORT FOREIGN SCHEMA public
FROM SERVER my_remote_server
INTO remote_data;

これだけで、`public` スキーマにある全テーブルが `remote_data` スキーマの中に爆速で生成される。めちゃくちゃ楽だよね。

—

ただ、実際の現場では「全部インポートするとゴミまで入ってくる」というケースがほとんどじゃないかな。そんな時は `LIMIT TO` や `EXCEPT` を賢く使おう。

「ユーザー管理系のテーブルだけ同期したい」なんて時は `LIMIT TO` が大活躍する。

IMPORT FOREIGN SCHEMA public
LIMIT TO (users, profiles, settings)
FROM SERVER my_remote_server
INTO remote_data;

逆に「巨大なログテーブルだけは外したい」という時は `EXCEPT` を使えばいい。

IMPORT FOREIGN SCHEMA public
EXCEPT (access_logs, debug_trace)
FROM SERVER my_remote_server
INTO remote_data;

これを知っているだけで、インポート後のクリーンアップ作業が劇的に減るはずだ。

—

ここで一つ、先輩からの大事なアドバイス。

`IMPORT FOREIGN SCHEMA` はあくまで「テーブル定義」をコピーするものだ。リモート側にあるインデックス（主キーやユニーク制約を含む）は、この構文では自動的に同期されないという点には注意が必要だよ。

もしクエリのパフォーマンスを気にするなら、インポート後に手動で適切なインデックスをローカル側の外部テーブルに対して定義しておく必要がある（※外部テーブルに対してインデックスを貼ることは可能だ）。

「あれ？ FDW使ってるのにクエリが遅いな？」と思ったら、ここを見落としていないかチェックしてみてくれ。

—

`IMPORT FOREIGN SCHEMA` は、単なる便利機能じゃない。これは「データモデリングの同期を自動化する」ための第一歩なんだ。

CI/CD パイプラインの中にこの定義更新スクリプトを組み込んでおけば、リモート側の変更に即座に追従できる。「DBの定義が古くてエラーになった」なんていう悲しい事故を未然に防ぐことができるんだ。

もし君のプロジェクトで外部サーバーとの連携が多いなら、今日からこの構文を意識してみて。きっと、君のDB管理が少しだけ、いや、だいぶ楽になるはずだよ。

何か詰まったら、いつでも聞きに来てね。一緒に快適なPostgreSQLライフを送ろう。