普通は覗く機会の少ないWordPressのデータベースの構造ですが、僕が分析した範囲でその仕組みについて書いています。

データベースについて

リレーショナルデータベース

フロントエンドの方は、データベースやSQLのことを良くご存知でない方もいらっしゃるかも知れません。

データベースと言うと、狭義にはリレーショナルデータベースを指しますが、リレーショナルというのは、「関係」というような意味です。

データベース内にはExcelの表のような「テーブル」がいくつか存在するのですが、そのテーブル同士の関係性を上手く使って、効率的な「クエリ（問い合わせ）」を行うので、そのような名前なのだと思います。

SQL

その「クエリ（問い合わせ）」を行うのが、SQLという言語になります。

僕自身は、PCで遊び始めたきっかけが、ExcelVBAやAccessだったので、最初に覚えた言語がちょうどSQLだったようなものです。

表形式であるデータベースのテーブルの一行を「レコード」と呼ぶのですが、レコードをテーブル同士の関係性を効率的に使って、追加・削除・更新するのがSQLの役目です。

データベース設計から学べること

データベース設計の目標を簡単に言うと、同じ項目を2回も3回も書かないで良いシステムを作ることです（これを「正規化」と言います）。

僕かつての職場の経験（パソコン教室のアルバイトでした）ですが、お客さんと取引があったときに、取引の記録を2箇所・3箇所とノートに書かなくてはなりませんでしたが、本当に非効率的で、仕事が嫌になってしまいました。

データベースを上手く使えば、そのようなことにならなくて済んだのです（何故パソコン教室で、ノートを使って帳簿を付けていたのか、まるで説得力の無い話でした）。

愚痴になってしまいましたが、データベース設計を学ぶと、色々な局面で、システムの無駄に気付けるようになると思います。

またデータベースの検索アルゴリズムの知識なども、コンピュータの処理速度に関する理解が深まり、オススメします。

プログラミング初心者にとっても割と簡単な言語ですので、、ご自身の事務仕事でExcelを使うときに、SQLiteなどと連携させてシステムを作ることなどを学習のきっかけにされると、とても良いと思います。

WordPressのデータベース構造

WordPressのデータベースには、テーブルが14個ほどありますが、このうち2個は珍しいことに、ここ最近(2019年9月)のアップデートで追加されたばかりです。

また、プラグインによってテーブルが追加される場合もあります。

では、メインとなるテーブルの項目（フィールド）と役割を、まずご説明しましょう。

wp_options

このテーブルは、WordPressの全体的な設定を司ります。

このテーブルの項目は、”ID”、”option_name”、”option_value”、”autoload”の4つしかありません。

これがAPIによって、”option_name”を指定したときに、”option_value”の値を取得したり、変更したりできるようになっています。

WordPressのインストール（「ようこそ」の画面）が済むと、”wp_options”にはちょうど100行のレコードが追加されますが、その内容は、

  • “siteurl”: WordPressディレクトリの位置
  • “home”: ホームURL
  • “blogname”: ブログ名
  • “blogdescription”: ブログの説明

などといった項目に始まり、他には例えばパーマリンク構造の文字列 (“permalink_structure”) とか、メディアサイズとか、管理画面の「設定」の項目のほとんどの情報がここに格納されます。

wp_posts

このテーブルは、投稿データのベースとなる情報管理を司り、項目も多数あります。

  • ID
  • 筆者ID
  • 投稿日時 (標準時間)
  • 投稿日時 (日本時間)
  • 投稿コンテンツ (出力されるHTML)
  • 投稿タイトル
  • 抜粋
  • スラグ
  • 更新日時 (標準時間)
  • 更新日時 (日本時間)
  • 親の投稿ID
  • 投稿タイプ

などあります。

メニューの項目など、一見「投稿」ではないような内容（ダジャレ？）も「投稿」扱いになっており、次に説明する “wp_postmeta” に格納される情報とセットで機能しています。

僕はGUI管理ツールを使い、開発の初期段階で、最初に必要な投稿記事 (aboutページ、contactページなど多数の固定ページ) を一度に書き込んだりする作業や、何らかのデータの一括変換をよく行い、少しは時短になっています。

wp_postmeta

このテーブルは “wp_posts” の補助的な情報を格納している重要なテーブルです。

拡張された機能に関する情報が多いようですね、アイキャッチ画像とか、カスタムフィールドとか。

以前、カスタムフィールドの項目をクエリするプログラムを作っているとき、複数値を持てるフィールドは、どうなっているのだろうかと調べました。

すると、一つのレコード内に配列的な手法で格納されていたのです。

これが分かったとき、”like”検索で複数値を持つフィールドの検索を行えば良いことが分かり、役に立ちました。

wp_terms

タームの情報を格納しています。

ID、スラグ、名前、タームグループの項目があります。

wp_term_taxonomy

カテゴリー、タグ、カスタムタクソノミーなど、タームがどのタクソノミーに属するかと、タームの説明や親タームなどの項目があります。

メニューも一つのタクソノミーになっていて、ユーザーが作った個々のメニューが “wp_terms” に一つのタームとして格納されます。

wp_term_relationships

投稿IDに対してタームを紐づけているテーブルです。

メニューは各項目の主要な情報を “wp_posts” と “wp_postmeta” に格納しつつ、 “wp_term_relationships” でターム名として個々のどのメニューに属するかを管理しています。

それ以外

ユーザー情報やコメント・リンクに関するテーブルがあります。

でも基本的には、データベースはいじらなくて良い

仕組みは知って置いて損しませんが、基本的にはデータベースをいじって、ID等が変わってしまうと、それに紐づく全ての設定が狂ってしまいます。

僕はちょっと変な性格でして、フロントページのIDは絶対 “1” にしたいとか、固定ページのIDやタームのIDの並び順などにこだわりがあるので、WordPressを立ち上げた直後、データベースをいじくり回して初期設定を全て終わらせてしまいます。

でも、基本的にはそんな使い方はしなくても、WordPressで用意されたAPIを使えば、全て事は済む話なのです。

この記事の内容が、何かの役に立てば幸いです。