【入門編】 IMPORT FOREIGN SCHEMA構文 – PostgreSQL

こんにちは！データベースを触っていると、「あっちのサーバーにあるデータを、こっちでもパッと見られるようにしたいな」って思うこと、ありますよね。

特に、仕事で複数のシステムが連携していると、「あっちのデータベースの表（テーブル）の形が変わったから、こっちの設計も直さなきゃ……」なんていう、地味で面倒な作業が発生しがちです。

今日はそんな時に役立つ、PostgreSQLのちょっと賢い魔法の呪文、`IMPORT FOREIGN SCHEMA`についてお話しします。

—

皆さんは、誰かから「この資料、最新版にしておいて」と頼まれて、手書きで内容を書き写した経験はありませんか？頑張って写したのに、あとから「あ、ここも修正忘れてた！」なんてなると、目も当てられませんよね。

データベースの世界でも同じです。別のサーバーにあるデータを使いたいとき、普通なら「こっちのサーバーにも同じ箱を作って、中身を合わせる」という作業が必要です。でも、相手のデータ構造が変わるたびに手作業で修正していたら、いつか必ずミスが起きます。

そこで登場するのが `IMPORT FOREIGN SCHEMA` です。

これは、「あっちのサーバーにある棚の中身を、そのままこっちにも『映し鏡』として表示させてね！」とお願いするコマンドなんです。

このコマンドの何がそんなに素晴らしいのか、3つのポイントでまとめてみました。

「手書き」が不要になる： 相手のテーブル定義をいちいち確認して、`CREATE TABLE` を叩く必要がありません。コマンド一つで、相手の構造を読み取って自動で「映し鏡」を作ってくれます。
同期のミスが激減する： 相手のシステムがバージョンアップして列が増えたりしても、設定を再読み込みすればすぐに対応できます。人間がうっかりミスをする余地が減るのは、エンジニアにとって一番の幸せですよね。
「別居」している安心感： 実際のデータは相手のサーバーにあります。こちらのサーバーはあくまで「窓口」のようなものなので、万が一こちらで誤ってデータを消してしまっても、本家（相手のサーバー）まで壊してしまう心配がありません。

難しいコードの細かい話は一旦置いておいて、雰囲気だけ掴んでみてください。こんな風にお願いするんです。

IMPORT FOREIGN SCHEMA public
FROM SERVER 外部サーバー名
INTO 自分のスキーマ名;

これだけで、相手のサーバー（`外部サーバー名`）の `public` スキーマにある棚を、自分のところの「映し鏡」として一気に作成してくれます。まさに魔法ですよね！

ただ、この魔法にも少しだけ注意点があります。

それは「相手のサーバーに負荷がかかる可能性がある」ということです。頻繁にデータを読みに行くと、相手のサーバーにとっては「何回も覗きに来るなよ〜！」と負担に感じてしまうかもしれません。

「便利だからといって、やりすぎない」というのは、データベースの神様からの教訓です。必要な時に、必要な分だけ使うのが、スマートなエンジニアの流儀ですね。

—

初心者の頃は、「全部自分で作らなきゃ！」と気負ってしまいがちです。でも、プロの現場では「いかに楽をして、いかにミスを減らすか」を常に考えています。

`IMPORT FOREIGN SCHEMA` は、まさにそんな「ラクをしてミスを減らす」ための強力な武器です。もし仕事で「データの連携が必要だな」と思ったら、ぜひこの魔法を思い出してみてください。

また何か気になることがあれば、いつでも聞きに来てくださいね。皆さんのデータベースライフが、少しでも快適になりますように！