なぜ「スキーマ」の管理が重要なのか
DBAの実務において、データベース内のオブジェクト整理は避けて通れない課題です。特に開発規模が大きくなると、単一の public スキーマにすべてのテーブルを詰め込む設計では、名前の衝突や権限管理の複雑化を招きます。スキーマを適切に分けることで、機能単位での名前空間の分離、論理的なデータ構造の整理、そして特定のグループに対する権限の一括制御が可能になります。本記事では、PostgreSQLの CREATE SCHEMA コマンドを用いた効率的な管理手法を解説します。
基礎知識：スキーマとは何か
PostgreSQLにおけるスキーマとは、テーブル、インデックス、ビューなどのデータベースオブジェクトを保持する「フォルダ」のようなものです。デフォルトでは public というスキーマが用意されていますが、これをそのまま使うのは小規模なアプリまでにとどめるべきです。スキーマを使用することで、異なる役割を持つテーブルを論理的にグループ化し、管理性を向上させることができます。なお、スキーマ名は pg_ で始めることが禁止されている点に注意してください。
実装と解決策
スキーマ作成には適切な権限が必要です。基本的にはデータベースに対する CREATE 権限を持つロールで実行します。
1. 基本的な作成: シンプルにグループ分けをする場合に用います。
2. 所有者の指定: AUTHORIZATION 句を使用することで、特定の業務担当ロールにスキーマの管理権限を委譲できます。
3. オブジェクトの同時作成: スキーマ作成と同時に初期テーブル等を定義することで、マイグレーションスクリプトを簡潔に保つことができます。
サンプルプログラム
以下は、開発環境の構築やCI/CDパイプラインでも利用可能な、スキーマ作成から初期オブジェクト定義までの一括実行コード例です。
/
- 1. 基本的なスキーマ作成
- 既存のスキーマと重複しないように注意してください
/
CREATE SCHEMA sales_dept;
/
- 2. 特定のロールを所有者として作成
- ‘analytics_user’ ロールがこのスキーマの所有者となります
/
CREATE SCHEMA report_schema AUTHORIZATION analytics_user;
/
- 3. スキーマ作成と同時にテーブルを定義
- 複数のコマンドを記述する場合、セミコロンの位置に注意が必要です
/
CREATE SCHEMA audit_log
CREATE TABLE access_logs (
id SERIAL PRIMARY KEY,
user_id INT NOT NULL,
accessed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)
CREATE INDEX idx_access_logs_user_id ON access_logs(user_id);
— 確認用コマンド
— \dn でスキーマ一覧を表示
— \dt audit_log. で作成したテーブルを確認
\dn
\dt audit_log.
応用・注意点
現場で活用する際の重要な注意点を挙げます。
・検索パス（search_path）の管理: スキーマを分けると、テーブル参照時に「スキーマ名.テーブル名」と書く必要があります。頻繁に使うスキーマは ALTER ROLE … SET search_path TO … でデフォルトの検索パスに指定しておくと、クエリが大幅に短縮されます。
・権限の継承: スキーマを作成しただけでは、他のユーザーはその中のテーブルにアクセスできません。必ず GRANT USAGE ON SCHEMA … TO … を実行し、必要な権限を付与する手順を忘れないようにしてください。
・トランザクションの活用: CREATE SCHEMA はトランザクション内で実行可能です。もしスクリプトの途中で失敗した場合にロールバックしたい場合は、BEGIN; と COMMIT; で囲んで実行することを強く推奨します。
コメント