目次

はじめに

第1章 データベースを始めよう

1.1 データベースという概念
1.2 データベースを管理する
1.3 データを破壊から守る
1.4 関係モデルとは
1.5 なぜDBMSを使うのか

第2章 PostgreSQL概要

2.1 PostgreSQL前史
2.2 PostgreSQLの開発形態
2.3 PostgreSQLの特徴
2.4 なぜPostgreSQLを使うの?
2.5 日本PostgreSQLユーザー会

第3章 PostgreSQLをインストールしよう

3.1 LinuxへのPostgreSQLのインストール
3.2 既存のPostgreSQLをアンインストール
3.3 YUMリポジトリの登録
3.4 PostgreSQLインストール
3.5 postgresユーザーの環境変数

第4章 データベースを作成しよう

4.1 データベースの作成?
4.2 データベースクラスタ
4.3 initdb
4.4 データベースクラスタの構成
4.5 起動
4.6 psqlでデータベースに接続
4.7 通常使用するユーザーを作りましょう
4.8 切断
4.9 停止

第5章 テーブルを作ろう

5.1 またデータベース?
5.2 スキーマ
5.3 テーブルの作成
5.4 テーブルの情報を確認

第6章 SQLでデータを操作してみよう

6.1 INSERT
6.2 SELECT
6.3 結合
6.4 UPDATE
6.5 DELETE
6.6 COPY

第7章 トランザクションと同時実行制御

7.1 トランザクション
7.2 同時実行制御
7.3 トランザクション分離レベル
7.4 psqlでのトランザクション
7.5 データ永続化の鍵を握るWALファイル

第8章 プログラムからPostgreSQLを操作しよう・準備編

8.1 何を作るのか?
8.2 プログラミング言語
8.3 CUI?GUI?
8.4 Webページのデザインは?
8.5 ドライバ
8.6 オブジェクト関係マッピング
8.7 月の計算
8.8 データベースの準備

第9章 プログラムからPostgreSQLを操作しよう・実践編

9.1 ページテンプレートの作成
9.2 トップページの作成
9.3 職員一覧ページ
9.4 職員追加・削除機能の追加
9.5 シフト表示画面
9.6 当日シフト表示画面
9.7 シフト入力機能の追加
9.8 シフト削除機能の追加
9.9 さらに発展させるには
9.10 ORMの功罪

第10章 追記型アーキテクチャとVACUUM

10.1 追記型アーキテクチャ
10.2 不要領域の再利用
10.3 VACUUM FULL

第11章 止まらないデータベースシステムを構成しよう

11.1 冗長化
11.2 ストリーミングレプリケーション
11.3 非同期レプリケーション
11.4 ストリーミングレプリケーションの仕組み

第12章 データが壊れても元に戻せるようにしよう

12.1 バックアップの目的
12.2 リカバリ要件を決める
12.3 オフラインバックアップ
12.4 オンラインバックアップ
12.5 論理バックアップ
12.6 物理バックアップ
12.7 ポイント・イン・タイム・リカバリ(PITR)

第13章 性能問題の調査と改善のヒント

13.1 データベースの性能調査の前に
13.2 性能調査の準備
13.3 性能問題ケース
13.4 CHECKPOINT
13.5 ディスクI/Oを分散する

第14章 セキュリティと監査

14.1 データベースにおけるセキュリティ
14.2 認証・アクセス経路の制限
14.3 必要なデータを必要なユーザーに
14.4 データの暗号化
14.5 データベースにおける監査機能
14.6 監査方針
14.7 監査に必要なデータ
14.8 ログの保存
14.9 定期的なチェック
14.10 PostgreSQLにおける監査ログですが……

第15章 他のDBMS の紹介

15.1 Oracle Database
15.2 MySQL
15.3 MongoDB

付録A PostgreSQLのWindowsへのインストール

A.1 インストーラのダウンロード
A.2 インストールの実行

付録B GUIでPostgreSQLを操作してみよう

B.1 pgAdmin 4
B.2 インストール
B.3 起動
B.4 サーバーの追加
B.5 データベースの追加
B.6 テーブルの作成
B.7 SQLを実行する
B.8 使用言語変更
B.9 その他の機能・注意点

あとがき

はじめに

 「データベースって何?」「どうしてデータベースなの?」「データベースってどうやって使うの?」あなたはこう聞かれてなんと答えるでしょうか。

 本書は、データベース初心者が、データベースとは何かをオープンソースソフトウェアのRDBMSであるPostgreSQLの使い方を通して学習することで、データベースやPostgreSQLについて知る第一歩となることを目的とした本です。

 本書を執筆するまで、筆者は『PL/SQLをPL/pgSQLにする本』、『わたしとぼくのPL/pgSQL【基礎編】』などの同人誌を執筆しました。大変ありがたいことに、どれも必要とされている方に読んでいただくことができ、「参考になった」など嬉しい言葉をいただくことができただけでなく、『わたしとぼくのPL/pgSQL【基礎編】』にいたってはインプレスR&Dより電子書籍として商業出版していただくこともできました1。多少は世の中の役に立つものが生み出せたのではないかと自負しています。

 しかし、いずれもある程度PostgreSQLを使用している人がターゲットであり、完全な初心者の方にはハードルが高いものでした。PostgreSQLは初心者向けの市販の入門書が充実していますし、同人誌を書くなら同人誌でしか書けない内容がいいと考えていたからです。

 そう思っていた筆者が入門書となる本書を執筆しようと思ったきっかけは、即売会でブースに来ていただいた方と話していると、PostgreSQL使用者が想像以上に少ないことでした。

 いえ、使用者が少ないのは予想していました。中にはPostgreSQLの存在そのものを知らなかったり、データベースのことは今勉強中という方や、データベースのことをほとんど知らない方が、予想以上に多かったのです。

 そういったデータベース初心者のために、データベースとは何か、そしてPostgreSQLとは何かをきちんと教える本が必要とされている……と感じました。データベース初心者がPostgreSQLを学ぶことで、PostgreSQLユーザーを増やすことにもなるのでは。と考え、本書を執筆しました。

 そのような経緯もあり、本書では以下のような読者を想定しています。

 ・データベースのことはよくわからないが、勉強したいという方

 ・データベースは使った経験があるが、PostgreSQLはよくわからないという方

 ・教育などでPostgreSQLを教えたいが、ちょうどいい教材がないという方

 ・昔データベースの経験があり、もう一度復習したいという方

 また、申し訳ありませんが、LinuxやWindowsの基本的な操作をすべて説明しているわけではありません。不安がある方は別途学習の上で読み進めてください。

 PostgreSQLが誕生してから20年以上、関係モデルの提唱から約50年になります。本書の内容は目新しいものはないかもしれませんが、初心者から教育を任されたベテランまで、データベースに関わるすべての方に読んでいただけるものを目指しました。

 本書を読めば、いっぱしのPostgreSQL使いになれること間違いなし(当社比)です!

 なお、2019年10月3日にPostgreSQL 12がリリースされました。本書の内容は9.6~12.0を使うことを想定しています。できる限りバージョン間で違いがある点については文章内で補足しますが、実践する場合は使用するバージョンに注意するようお願いします。

1. 『わたしとぼくのPL/pgSQL』Amazon他多数の電子書籍プラットフォームで販売中です。https://nextpublishing.jp/book/10498.html

第1章 データベースを始めよう

 「データベースって何?」と聞かれて、ちゃんと答えられる人はあまり多くありません。アプリ開発をメインで行っているエンジニアなら「データを入れておく箱」くらいに思っているかもしれません。その解釈、間違ってはいませんが、一見シンプルにデータを出し入れできるその箱が実は、ユーザーがシンプルにデータを扱えるように複雑な仕組みを持っており、データを守る堅固な機構を備えていることは、知っておいてほしいところです。

 データベースを使い始める前に、まずはデータベースとは何かを説明します。

1.1 データベースという概念

 データベースといっても、特に難しい概念ではありません。スマホに入っている連絡先、メールが格納されているメールボックス、電子データ以外では紙の辞書、最近めっきり見なくなりましたがタウンページのような電話帳も、データベースと言えないことはありません。

 端的に言いますと、データベースとは、「参照したり修正したりできるデータの蓄積」のことです。

1.2 データベースを管理する

 「データベース」という概念の意味はおわかりいただけたでしょうか。しかし、いかに膨大なデータが蓄積されていてもそれが整理されていなければ使いにくく、どんなに有益なデータでも有効に使えなければ宝の持ち腐れです。また、量が多すぎて更新するのも一苦労で、更新漏れがないように確認するだけでも大仕事となると、誰もデータをアップデートできず、結果としてデータの価値が落ちてしまいます。

 そんなデータを簡単に検索したり、矛盾なく更新したり、使いやすく管理可能にするソフトウェア。そのような製品を、「データベースマネージメントシステム(Database Management System)」略してDBMSといいます。

 図書館で例えてみましょう。本一つ一つがデータです。どんなに有益な本がたくさんあったとしても、それらが雑然と積まれているだけでは、利用者は読みたい本を探すのも大変ですし、どんな本があるのか把握するのも一苦労でしょう。

 探しやすいようしっかりと本を分類して本棚にしまい、時には利用者からの問い合わせに対応して本を探す。古くなった本の補修を行うこともあるでしょう。図書館で言えば、司書や図書館職員にあたるのがDBMSです。

1.3 データを破壊から守る

 DBMSは、データベースを扱いやすくする以外に、もう一つ大きな使命を持っています。

 それは、「データを破壊から守ること」。なぜデータを守ることがそんなに重要なのでしょうか?

 考えてもみてください。あまり意識しないだけで、実は世の中にはたくさんのデータベースで溢れています。それらのデータベースは、私達ユーザーが直接いじることはほとんどなく、何かしらのアプリケーションを介して操作します。

 もう一度、図書館で例えてみましょう。

 本がデータ、図書館の本棚がデータベース、図書館の利用そのものがアプリケーションです。図書館の価値は何で決まるでしょう?立地や見た目の良さなども重要ですが、蔵書は傷だらけ、ところどころ抜けているページがある、整理されておらずどこに何があるかわからない、どこの本屋にでも置いてあるような雑誌はたくさんあるのに図書館にこそ求められる学術的な本はない……そんな図書館に価値はあるでしょうか?どんなにきれいな建物でもそんな図書館に用がある人は少ないですよね。

 つまり、データの価値がシステムの価値を決めると言っても過言ではないのです。しかし、そのデータはちょっとした操作で壊れてしまいやすいものなのです。

 データの破壊にはふたつの種類があります。ひとつは保存している媒体そのものが故障してしまう「物理的破壊」。もうひとつは、データが現実と乖離したり、データが相互に矛盾してしまったりする「論理的破壊」です。

 図書館の例えを続けると、紙の本はちょっと乱暴に扱うだけで破れますし(物理的破壊)、元あった本棚に戻さないと、その本がどこにあるのか探すのが大変になりますよね(論理的破壊)。

 このふたつの破壊からデータを守る。これがDBMSの使命であり、そんな壊れやすいデータを守る最後の砦、それがDBMSです。したがって、DBMSにはデータを破壊から守るための管理方法や機能がたくさん搭載されています。

1.4 関係モデルとは

 では、どのようにすればデータを破壊から守れるのでしょうか。昔から、「こうすればデータを管理しやすくできる」と考えた人が、様々な管理手法やデータのモデルを考案してきました。そしてそのたびに、その管理方法を実装したDBMSがいくつも世に出てきました。

 データの管理方法の概念の一つであり、現在主流となっているのが、「関係モデル」です。英語で「リレーショナルモデル」ということもあります。

 関係モデルとは、IBM社員だった故エドガー・F・コッド氏1が、数学の集合論と述語論理に基づいて考案し、1970年に提唱したデータ管理モデルで、データを縦軸と横軸の二次元表のような形式2で扱うものです。

 たとえば、書籍を関係モデルで表してみましょう。

 まずデータが持つ属性を決めます。書籍なら、「タイトル」「著者」「出版社」「発行年月日」「価格」などでしょうか。架空の書籍ですが、たとえばこのようになります。

図1.1: 書籍の属性

 他の書籍も、同様に表現してみましょう。

図1.2: 書籍の集合

 どうでしょうか。同じ属性を持つデータの「集合」が、まるで縦横の二次元表のように見えてきたのではないでしょうか。実際に、関係モデルではこの「集合」のことを「テーブル」、つまり「表」と呼びます。

 このテーブルがいくつも存在し、テーブル同士を関連付けてデータを管理できます。そのため、「テーブル同士を関連付けてデータを管理できるから、『関係モデル』というんだ」という誤解がよく見受けられます。実際は、関係モデルではテーブル同士の関連のことを「関係」と呼んでいるのではなく、この「集合」のことを、「関係」と呼びます。

 このモデルは人間的にもわかりやすく、非常に有効で、現在でも主流となっています。

 この関係モデルを実装してデータを管理するDBMSを、「リレーショナルデータベースマネージメントシステム(Relational Database Management System)」、略してRDBMSといいます。

 そして、本書で扱うPostgreSQLも、RDBMS製品の一つです。他のRDBMS製品として有名なところでは、Oracle Database、MySQL、SQL Serverなどがあります。

 しかし、この関係モデルの概念が提唱されたのはおよそ半世紀も前。そんな昔に提唱された理論が現在なお主流となっているのですから、いかに安定した理論であるかがわかるというものです。

1.4.1 関係モデルの用語

 RDBMSでよく使う用語をここで解説します。

表(テーブル)

 関係モデルでいうところの「関係」、すなわちデータの集合。これを「表」や「テーブル」といいます。数学的には「集合」。関係モデルの概念では「関係」。関係モデルを実装したDBMSでは「テーブル」といい、細かい違いはありますが、すべて同じ概念を違う言葉で言っているようなものです。普段の会話でデータベースの話をするときは、「テーブル」といえばみんなわかってくれるでしょう。

列(カラム)

 テーブルで表現したときに、縦の列になるものです。すなわち、ある集合の属性のことです。

行(レコード、タプル)

 テーブルで表現したときに、横の行になるものです。すなわち、ある集合の1件のデータのことです。一般的には「レコード」ということが多いですが、PostgreSQLでは「タプル」と呼ぶことも多いです。

図1.3: 関係モデルの用語

キー

 テーブルで重要な意味を持つ列のことを「キー」や「キー列」といいます。特に、その列の値が決まればそのテーブルの中でレコードが1行に特定できるキーのことを、テーブルの「主キー」とか、「プライマリキー」などといいます。1行に特定しなければならないので、主キーはテーブル内で重複はありません3

 たとえば世の中には同じタイトルのつけられた本が山程ありますが、ISBNという全世界の書籍一つ一つにつけられたコードがわかれば、そのなかから1冊の書籍を特定できます。同じISBNが全く異なる書籍に振られていたら、ちょっと世間が混乱するでしょう。

1.5 なぜDBMSを使うのか

 データベースについて説明してきましたが、皆さんの中には「DBMSをいちいち使わなくても、表計算ソフトやCSVなどのテキストベースのファイル管理でも別にいいんじゃないの?」と思った方がいるかもしれません。

 筆者自身データベースをよく知らなかったときはそう思いましたし、データベースにあまり詳しくない人にそう言われたこともあります。

 DBMSを使うと何が便利なのか?たとえば次のような点が挙げられます。

1.5.1 同時にデータにアクセスできる

 たとえば、あなたの会社ではExcelで作成したプロジェクトの管理表がファイルサーバーに置いてあり、各自がそれぞれアクセスして更新していませんか?4

 そういう運用をしているところでは、「誰かが更新してるから自分が更新できない」とか、「自分がローカルで更新したファイルをサーバにアップロードして、誰かが更新した内容を消してしまった」ということを体験した人も多いと思います5

 DBMSを使えばこのようなことを心配する必要はありません。同時にデータにアクセスする仕組みをきちんと備えているからです。

1.5.2 大容量データを扱える

 あなたは何10メガも何100メガもあるExcelファイルを開かざるを得なかったことはありませんか?それなりの性能のPCでも、まず開くだけで時間がかかります。Excelは1シートにつき100万行以上のレコードを扱えますが、実際に100万行データを入れることはまずないでしょうし、数千から10000行でもExcelにしては多いな、と思います。

 また、何100メガのテキストファイルをエディタで開き、必要な行を見つけてデータの参照や更新をするのは一苦労というのは容易に想像できることでしょう。

 RDBでは何10メガ何100メガは当たり前。ギガ単位はざらにあります。100万行のレコードを保持しているテーブルなんてゴロゴロあります。何億行だって存在します。

 それでも高速に必要なデータを参照したり更新したりできる仕組みが存在しています。

1.5.3 データの矛盾・重複を防ぐ

 Excelのような表計算ソフトやCSVのようなテキストファイルでは、データの分散と重複が防げません。そのため、あるデータを更新するために複数のシートやファイルを更新しなければならず、更新漏れを防ぐのは本人の努力以外にありません。

 また、本来ならば数値を入れるべき箇所に誤って文字を入力した場合、エラーとして弾くのも難しいでしょう。

 DBMSなら、このようなデータの矛盾や重複を防ぐ仕組みがあります。

1.5.4 別テーブルを関連付けて検索できる

 この機能がRDBMSの真骨頂と言っていいでしょう。複数のテーブルを同時に検索し、検索結果としては一つの表として表示できます。プログラムを書かずにExcelやCSVで同じ芸当をこなすのはかなり難しいでしょう。

  

 どうでしょう、DBMS、特にRDBMSについて、なんとなく理解できたでしょうか。ではデータベースについて理解できたところで、次章では本書で扱うPostgreSQLというRDBMSについて、もう少し詳しく説明します。

1. 1923年~2003年。イングランド出身の計算機学者。関係モデルを考案したすごい人。

2. 厳密にはあくまでも「二次元表のような形式」であり、二次元表そのものではありません。初心者のうちは「ふーん、そういうものか」と思っていてください。

3. この特性を、「一意である」とか「ユニークである」とかいいます。一意は日常ではまず使わない言葉ですし、ユニークも普段使っている意味とは異なりますが、RDBMSでは非常によく使われるので注意してください。

4. 筆者はそういう運用をしています。つらい。

5. 筆者はよくやります。つらい。

第2章 PostgreSQL概要

 第1章「データベースを始めよう」ではRDBMSのごく基本的な知識を学習しました。世の中にはさまざまなRDBMSがありますが、本書ではPostgreSQLを扱います。本章ではPostgreSQLというRDBMSがどういうものかをご紹介します。

2.1 PostgreSQL前史

 PostgreSQL。日本語では「ぽすとぐれえすきゅーえる」と読み、略して「ぽすぐれ」とか、「ぽすとぐれす」などと言ったりもします。

 PostgreSQLの大本をたどると、カリフォルニア大学バークレイ校の助教授だったマイケル・ストーンブレーカー氏1が、「1.4 関係モデルとは」で登場したコッド氏の論文を読み、RDBMSの研究として1973年に開発を始めたIngres2に突き当たります。

 Ingresで採用した関係モデルに行き詰まりを感じたストーンブレーカー氏は、Ingresの後継となるプロジェクトを始めます。それがPOSTGRES(Post-INGRES)プロジェクトです。

 POSTGRESは研究用や教材、商用として広まったのですが、ユーザー数が増えた結果ソースの保守開発に研究室のリソースの大半が取られてしまうということで、1993年にPOSTGRESプロジェクトはPostgres 4.2をリリースして正式に終了します。

 翌1994年、Postgres95がオリジナルのPOSTGRESバークレイコードの後続としてWeb上でリリースされます。さらに1996年名前を「PostgreSQL」に変え、バージョンを6.0としてリリースします。

 これが今日まで続くPostgreSQLの歴史の始まりです。

2.2 PostgreSQLの開発形態

 ソフトウェアは、売り物として販売されている商用ソフトウェアと、ソースコードが公開され、ライセンスさえ守れば誰でも無償で自由に使用や修正、さらに再配布が可能なオープンソースソフトウェアのふたつに大別できます。

 DBMSにもこのふたつが存在し、PostgreSQLは後者のオープンソースソフトウェアにあたります。

 同じオープンソースソフトウェアのRDBMSとして有名なMySQLは、開発はOracle社が中心となっていますが3、PostgreSQLは、現在もどの企業にも属さずコミュニティが中心となって開発が行われています。メジャーバージョンアップは原則1年に1回行われ、今も機能の拡充と性能向上が続けられています。

図2.1: 最近のバージョンアップと追加機能

 一昔、いや二昔くらい前までは、オープンソースソフトウェアというと、無料で利用できる分、商用よりも劣る品質のものであると考える人も多かったのですが、PostgreSQLは常に機能の拡充と性能の向上を行っており、商用DBMSと遜色ないくらいの機能と品質を持っています。今では実際のサービスでPostgreSQLや他のオープンソースソフトウェアのRDBMSが採用されていることは珍しくありません。

PostgreSQLのバージョン番号

 PostgreSQLのバージョンが9.6から10になったときに、小数点以下の数字がなくなったことにお気づきでしょうか。これは、10がリリースされたときに、小数点第一位までがメジャーバージョンを表していた従来のバージョン番号の方式を改め、整数部分がメジャーバージョン、小数点がセキュリティアップデートやバグフィックスでバージョンアップするマイナーバージョンとすることになったからです。

 どのPostgreSQLを使うか迷ったときは、とりあえず性能や機能が改善されている最新版を使うことをおすすめします。

2.3 PostgreSQLの特徴

2.3.1 ライセンス

 オープンソースソフトウェアはソースコードを公開しているとはいえ、決して権利を放棄しているのではありません。ちゃんとライセンスを公開しており、ライセンスに従わない場合は訴訟もありえます。

 オープンソースソフトウェアで広く使われているラインセンスはGPL(GNU General Public License)というものです。これは利用を認めているが、修正して再配布する場合は同じGPLライセンスで配布しなければならないという規約があり、ちょっと厳しいライセンスです4

 しかしPostgreSQLは独自の「PostgreSQLライセンス」というライセンスを使用しています。これはBSDライセンスをもとにしたライセンスで、ほとんど制限がありません。そのため、PostgreSQLをベースにした商用RDBMSも各社から発売されています。

表2.1: 各社から販売されているPostgreSQLベースの商用DB
企業 製品名 特徴
EnterpriseDB EDB Postgres Oracleとの互換性に優れている。
富士通 Enterprise Postgres 透過的データ暗号化機能を備えている。
Pivotal Greenplum マルチコアの並列処理が得意。

 表2.1に挙げたものはほんの一部に過ぎません。その他、Amazon RDS5でもPostgreSQLを使うことができますし、Amazon Aurora6もPostgreSQLと互換性があります。

 これらのRDBMSはベースがPostgreSQLとはいえ有償で販売しているものであり、購入費用やサポート費用が必要です。しかしコミュニティが公開しているPostgreSQLに関しては、当然、本書を執筆している筆者も、お読みいただいているあなたも、無償で自由に使用することができます。

2.3.2 豊富な拡張機能

 PostgreSQLはオープンソースソフトウェアであり、また比較的自由なライセンスを採用しているため、PostgreSQLの機能を補う拡張機能が有志によって開発・リリースされています。

 そのうちいくつかの拡張機能をご紹介しましょう。詳細は省きますので、使用する場合は各自調べてください。

pg_stat_statements

 SQLの性能問題はDBMSを使用する上で避けては通れない道です7。PostgreSQLには時間がかかったSQLをログに出力する機能は存在しますが、さらに情報を必要とする場合に有効となるのがこの拡張機能です。

 SQLごとの実行回数や平均実行時間など、SQLの性能を確認するのに重要な情報を取得することができます。

pg_hint_plan

 PostgreSQLでは稼働しているインスタンスから統計情報という情報を収集しており、SQLがどのように実行されるかは、統計情報からPostgreSQLが実行計画を決めて実行するため、使用者が制御するのは困難です。

 しかし、この拡張機能を使うと、SQLに実行計画を指示することができるようになります。便利な拡張機能なのですが、本来であればSQLの実行はPostgreSQL任せにするのが理想ですので、使いすぎには注意です。

pg_statsinfo

 PostgreSQL稼働状況を定期的に収集・蓄積してくれるツールです。日々の状況を把握でき、性能劣化の兆候や問題発生時の原因特定に役立ちます。

 同じ拡張機能のpg_stats_reporterと組み合わせることでブラウザ上からグラフィカルに収集した情報を確認することができます。

  

 他にもデータベースを停止することなくテーブルの再編が行えるpg_repack、バックアップとリストアをやりやすくするpg_rmanなど、数え切れないくらいの拡張機能があります。「こういう機能がないか」と疑問に思ったら、調べてみると何かしら出てくると思います。

2.4 なぜPostgreSQLを使うの?

 さて、本書ではこれから今までご紹介したPostgreSQLを使用します。しかし、他にもRDBMSはあるのに、なぜPostgreSQLなのか?と思った方もいるかも知れません。

 確かに、シェアで言えばOracle、MySQL、SQL Serverには遥かに及びませんから、覚えるならそちらのほうがお得だと考える人もいるでしょう。

 それなのになぜ、あえてPostgreSQLなのでしょうか。理由は以下の通りです。

 ・無償で使用できる

 PostgreSQLはオープンソースソフトウェアであり、かつライセンスでもかなり自由に使うことが許されています。初心者の練習にはもってこいと言えるでしょう。

 しかし、同じオープンソースのMySQLも当然無償で使用できますし、商用ソフトウェアであるOracleやSQL Serverも試用版があります。これだけではPostgreSQLを使う理由にはならないでしょう。

 ・標準SQLに準拠することを重視しており、SQLの練習にちょうどいい

 RDBMSは、データの定義や操作をSQLという言語8で行います。そして、ISOによって何年かに一度標準SQLというものが策定されており、PostgreSQLはこれに準拠することを重視しています。ですから、PostgreSQLでSQLを学ぶことで、他のDBMSを使うときにも応用できるでしょう。しかし、残念ながら100%標準SQLに準拠しているRDBMSは存在しません。SQLは製品ごとに方言があるのが当たり前9で、決まった製品を使う予定があるならそれを使うべきで、これも決め手には欠けます。

 ・今注目のDBMSの一つである

 これは本当です。ドイツのハイルブロンにあるITコンサルタント会社のsolid IT社が毎年発表しているデータベース・オブ・ザ・イヤー10に、PostgreSQLは2017年と2018年の2年連続選ばれました11。RDBMSに要求される機能を幅広く実装しており、開発コミュニティも活発で、技術者からも信頼があり、様々なシーンで採用が増えています。AWSでもAzureでも使用できるようになっていることから、今後も需要が見込めると思います。シーンの最前線に立ち続ける覚悟はあるという方は、使い方を覚えて損はないでしょう!

 ・好きだから

 結局のところ、これです。好きだから広めたい。みんなに使ってほしい。みんなに良さを知ってもらって、さらに広めてほしい。かなり個人的な理由ですがそれが一番大きな動機ですよね。

2.5 日本PostgreSQLユーザー会

 日本PostgreSQLユーザー会は、日本におけるPostgreSQLの普及と発展を主な目的とした、PostgreSQLユーザーによる組織です。

 イベントも定期的に行われており、そこでPostgreSQL有識者と交流することができます。

 その他にもメーリングリストで質問を投げかけることもできますし、日本語のSlackチャンネルもあり、初心者もたまに質問を投げかけていますが、親切な人が答えてくれます。ぜひ、何か困ったことがあったら活用してみてはいかがでしょうか。

試し読みはここまでです。
この続きは、製品版でお楽しみください。