Day1 後半のゴール
「実際に“1プロジェクト用のDBとユーザー”を作れるイメージを持つ」
前半で、PostgreSQL・psql・ロール(ユーザー)のざっくりした世界観はつかめました。
後半では、それを「1つのアプリ用データベースを用意する」という具体的なストーリーに落としていきます。
ここでのゴールは、頭の中でこう言える状態です。
PostgreSQLインストール直後に、どのユーザーでどうやって psql に入るかイメージできる。
psql 上で「DB一覧を見る → DBを作る → 接続を切り替える」という流れを説明できる。
アプリ用ユーザーを作り、そのユーザーにDBへの権限を与える一連のコマンドを、自分の言葉で追える。
コードを書く前の「最初の準備作業」を、怖がらずにイメージできるようにします。
インストール直後の“最初の一歩”を具体的にイメージする
「管理ユーザー postgres で psql に入る」
多くの環境では、PostgreSQL をインストールすると「postgres」という管理用ロール(ユーザー)が自動で作られます。
MySQL でいう root ユーザーに近い存在です。
最初の一歩は、「postgres ユーザーとして psql に入る」です。
環境によって細部は違いますが、イメージとしては次のような感じです。
ターミナルを開く。
postgres ユーザーで psql を起動する。
例えば、こんなコマンドを打つイメージです。
psql -U postgres
パスワードを聞かれたら、インストール時に設定した postgres のパスワードを入力します。
接続に成功すると、こんなプロンプトが出ます。
postgres=#
この「postgres=#」は、「postgres というデータベースに、postgres というユーザーで接続している」というサインです。
ここから、管理作業を進めていきます。
psql で“今どんなDBがあるか”を確認する
「\l と \c を体で覚える」
まずは、「このサーバーにどんなデータベースがあるのか」を見てみます。
psql では、メタコマンド \l を使います。
postgres=# \l
これで、template0 / template1 / postgres など、いくつかのDBが一覧表示されます。
template0 / template1 はテンプレート用のDBで、postgres は管理用のDBです。
次に、「別のDBに切り替える」イメージも持っておきましょう。
接続先を変えるには \c を使います。
postgres=# \c postgres
You are now connected to database "postgres" as user "postgres".
postgres=#
今はすでに postgres にいるので見た目は変わりませんが、「\c dbname で接続先を変える」という動きが大事です。
MySQL の USE dbname; に相当しますが、PostgreSQLでは SQL ではなくメタコマンドです。
新しいデータベースを作る流れを“物語”として覚える
「プロジェクト用の箱 myapp_db を作る」
ここから、「このサーバーに、アプリ用のDBを1つ用意する」というストーリーに入ります。
例えば、「myapp_db」という名前のDBを作るとします。
やることはシンプルで、管理ユーザー postgres で次のSQLを実行します。
CREATE DATABASE myapp_db;
SQL実行すると、「CREATE DATABASE」と表示されます。
これで、PostgreSQLサーバーの中に myapp_db という箱が1つ増えました。
次に、その箱に入ってみます。
postgres=# \c myapp_db
You are now connected to database "myapp_db" as user "postgres".
myapp_db=#
プロンプトが myapp_db=# に変わりました。
これが、「今は myapp_db の中にいる」というサインです。
ここまでで、「DBを作る → そのDBに入る」という一連の流れができました。
SQLite でいう「ファイルを作る → そのファイルを sqlite3 で開く」に相当しますが、PostgreSQLでは「サーバーの中の箱を増やす」という感覚です。
アプリ用ユーザー(ロール)を作る
「管理ユーザーとアプリユーザーを分ける、という発想」
実務では、管理用の postgres ユーザーでアプリから接続することはしません。
「アプリ専用のユーザー」を作り、そのユーザーにだけ必要な権限を与えます。
ここでは、「myapp_user」というアプリ用ユーザーを作る例で考えます。
ユーザー作成は、DBではなく「サーバー全体」に対する操作なので、どのDBにいても構いませんが、分かりやすく postgres DB に戻ってから実行してもOKです。
myapp_db=# \c postgres
postgres=#
そして、ユーザーを作ります。
CREATE USER myapp_user WITH PASSWORD 'strong_password_here';
SQLこれで、「ログイン可能なロール」が1つ増えました。
MySQL の CREATE USER と同じイメージですが、PostgreSQLでは「ロール」という言い方をします。
ここでの重要ポイントは、「管理ユーザー postgres と、アプリ用ユーザー myapp_user を分ける」という設計です。
セキュリティ的にも、事故防止の観点からも、これは必須の習慣です。
アプリ用ユーザーにDBへの権限を与える
「GRANT で“この箱はあなたが使っていいよ”と伝える」
ユーザーを作っただけでは、そのユーザーはまだどのDBにもアクセスできません。
「どのDBを使っていいか」を GRANT で教えてあげる必要があります。
先ほど作った myapp_db を、myapp_user に使わせたいので、こうします。
GRANT ALL PRIVILEGES ON DATABASE myapp_db TO myapp_user;
SQLこれで、「myapp_user は myapp_db に接続して、DBレベルの操作ができる」状態になります。
MySQL の GRANT ALL ON myapp_db.* TO 'myapp_user'@'localhost'; に近いイメージです。
ここまで来たら、一度 myapp_user で実際に接続してみると、理解が一気に深まります。
psql -h localhost -p 5432 -U myapp_user myapp_db
パスワードを聞かれたら、先ほど設定したものを入力します。
接続に成功すると、今度はこんなプロンプトになります。
myapp_db=>
ユーザー名は表示されませんが、「myapp_db に myapp_user で入っている」状態です。
このユーザーでテーブルを作ったり、データを入れたりしていくのが、アプリ開発の基本スタイルになります。
SQLite / MySQL との“手触りの違い”をもう一度整理する
「ファイル直叩きから、“サーバー+ロール+DB”の三層構造へ」
ここまでの流れを、SQLite / MySQL と比較しながら振り返ってみます。
SQLite の場合は、「ファイルを作る → そのファイルを sqlite3 で開く → そのままテーブル作成・データ投入」という、非常にシンプルな流れでした。
ユーザーや権限の概念はなく、「そのファイルにアクセスできるOSユーザーかどうか」が全てでした。
MySQL の場合は、「mysqld サーバーを立てる → root で接続 → CREATE DATABASE → CREATE USER → GRANT」という流れでした。
PostgreSQL は、ここまで見てきた通り、ほぼ同じ構造です。
違いは、「ユーザー=ロール」という考え方と、「psql のメタコマンド文化」です。\l でDB一覧、\c で接続変更、\dt でテーブル一覧、\d で定義確認。
これらをサクサク使えるようになると、「GUIがなくても全然困らない」レベルになります。
Day1 の時点では、「PostgreSQLは SQLite より一段“ちゃんとしたサーバー型”で、MySQL とほぼ同じ感覚で扱える。ただし、ロールとpsqlに少し慣れが必要」という理解で十分です。
Day1 後半のまとめ
PostgreSQLインストール直後は、管理用ロール postgres で psql -U postgres としてサーバーに入り、\l で既存DBを確認しつつ、CREATE DATABASE myapp_db; でプロジェクト用のDBを作り、\c myapp_db でそのDBに接続する、という流れで「アプリ用の箱」を用意する。
そのうえで、管理ユーザーに戻って CREATE USER myapp_user WITH PASSWORD '...'; でアプリ用ロールを作成し、GRANT ALL PRIVILEGES ON DATABASE myapp_db TO myapp_user; で「このDBはあなたが使っていい」と権限を与え、最後に psql -U myapp_user myapp_db で実際にそのユーザーとして接続してみることで、「管理ユーザーとアプリユーザーを分ける」「サーバーの中に複数DBを持ち、ロールに権限を割り当てる」という PostgreSQL の基本的な世界観と、psql メタコマンドを使った実際の操作の流れを、自分の中にしっかり刻み込む。

