WordPressのデータベースのテーブルってどうなってるの？
WordPressのデータベースについて自分用オボエガキです。
テーブル構成を把握しておくメリットとしては…
- 頭の片隅にでも置いておくと何気なく記述しているソースの理解が深まるかもしれない。
- プラグインによってテーブルが追加されることがあるが、必要がなくなった場合に不要なデータが把握しやすくなる。
- WordPressのコアの関数では取得が難しいもののSQLを実行すれば簡単なこともある。「wpdb」というクラスを使って、データベースにアクセスすることができる。（「$wpdb->posts」みたいな記述たまに見ますよね。） ※$wpdb->postsは「wp_posts」テーブルのデータを参照できます。
データベーステーブルの基礎
まずはテーブルの基礎から。
記事のネタがWordPressなので一番重要なテーブルである「wp_posts」テーブルの例で説明。
列のことをフィールド（もしくはカラム）と呼び、行のことをレコードと呼びます。
WordPressは11個のテーブルで構成されている
少ない…。
確かEC-CUBEは100個以上あったような。
サイトの内容によって意識した方がいいテーブルの順位は変わってくるかと思いますが、
個人的には「wp_posts」、「wp_postmeta」、「wp_terms」、「wp_term_taxonomy」、「wp_term_relationships」あたりを抑えておけばとりあえずはいいかなと思っています。
テーブル一覧
「黄色のセル」のテーブルは詳細を後述します。
| テーブル名 | 保存しているデータ |
|---|---|
| wp_posts | 投稿、固定ページ、メディア、カスタムメニュー、カスタム投稿、リビジョン等の投稿関連の主要なデータ |
| wp_postmeta | wp_postsのメタデータ。主にカスタムフィールド。 |
| wp_terms | カテゴリー・タグ・カスタムタクソノミーのターム名やそのスラッグの情報 |
| wp_term_taxonomy | カテゴリー・タグ・カスタムタクソノミーとターム名を関連付けるためのデータ。 |
| wp_term_relationships | カテゴリー・タグ・カスタムタクソノミーと投稿を関連付けるためのデータ |
| wp_user | 管理者等々のユーザー情報を格納しているテーブル。ユーザー名・パスワード・メールアドレス等を保存している。 |
| wp_usermeta | 各ユーザ特有のユーザ・メタデータを格納 |
| wp_comment | WordPressへのコメント・トラックバック・ピンバックデータを格納 |
| wp_commentmeta | 各コメントのメタデータと呼ばれる情報。 |
| wp_options | 管理画面メニューの「設定」で入力した情報を保存しているテーブル。 |
| wp_links | この機能は非推奨になりました、とCodexに書いてあるので無視することにします。 |
一覧重要な「wp_posts」テーブルの主なフィールドをチェック！
本当は「テーブルの基礎」の図の様に横書きにできればフィールド（カラム）とレコードのイメージが掴みやすいのですが、はみ出してしまうので縦書きにします。
「wp_posts」テーブルの主なフィールド
| フィールド名 | 保存されるデータ |
|---|---|
| ID | 投稿ID（保存順に自動採番） |
| post_title | タイトル |
| post_content | 本文 |
| post_excerpt | 抜粋 |
| post_status | ステータス：「公開済み」や「下書き」 |
| post_date | 投稿日時 |
| post_name | 投稿スラッグ |
| post_type | 投稿種別：投稿（post）、ページ（page）等 |
ちなみに「wp_posts」テーブルの内容は、グローバル変数「$post」の中身と一緒です。
その他、特筆すべきは「post_type」のところで、WordPressは投稿と固定ページが同じレコードに保存されているところ。ええーそうなの？という印象。
ここのデータが「post」、「page」かで判断しているようです。
「wp_postmeta」テーブルについて
「wp_posts」にカスタムフィールドを追加した場合は「wp_postmeta」テーブルにデータが追加されていきます。
ここが特殊だよWordPressテーブルの構造！
一般的に情報を追加する場合は同じレコードに対してフィールド（カラム）を追加するのですが・・・
WordPressの場合はちょっと異なる仕組みのようです。
「wp_posts」テーブルにフィールド（カラム）を追加していくのではなく、別のテーブルである「wp_postmeta」テーブルに情報が追加されます。
「wp_postmeta」テーブルに追加したカスタムフィールドの値を表示させるには「get_post_meta」 関数を使用します。
<?php echo get_post_meta( $post->ID , 'feeling' , true ); ?>
「get_post_meta」という関数名からもフムフム「wp_postmeta」テーブルの情報を引っ張ってきているのね、というのが推測できます。
分類を保存する３つのテーブル
これらも覚えておいた方が良さそうです。
- 「wp_terms」テーブル
- 「wp_term_taxonomy」テーブル
- 「wp_term_relationships」テーブル
個人的解釈としては下記のようなイメージです。 タクソノミー：映画 ターム：アクション/ホラー/コメディ…
- 「wp_terms」テーブルにターム「アクション/ホラー/コメディ…」情報を格納
- 「wp_term_taxonomy」テーブルで各ターム「アクション/ホラー/コメディ…」とタクソノミー「映画」を関連付け
- 「wp_term_relationships」テーブルでタクソノミー「映画」と投稿を関連付け
「wp_terms」テーブルの主なフィールド
※カテゴリー・タグ・カスタムタクソノミーのターム名やそのスラッグのデータが格納されています。
| フィールド名 | 保存されるデータ |
|---|---|
| term_id | タームのユニークID |
| name | ターム名 |
| slug | タームスラッグ |
「wp_term_taxonomy」テーブルの主なフィールド
※カテゴリー・タグ・カスタムタクソノミーとターム名を関連付けるためのデータが格納されています。
| フィールド名 | 保存されるデータ |
|---|---|
| term_taxonomy_id | ターム + タクソノミー ペアのユニークID |
| term_id | 「wp_terms」テーブルの「term_id」 |
| taxonomy | タームが属するタクソノミー |
| description | タームの分類上の説明。「カテゴリ説明」など |
| parent | 分類上のターム間の上下関係 |
| count | そのタームに属する投稿数の数 |
「wp_term_relationships」テーブルの主なフィールド
※カテゴリー・タグ・カスタムタクソノミーと投稿を関連付けるためのデータが格納されています。
| フィールド名 | 保存されるデータ |
|---|---|
| object_id | 記事ID |
| term_taxonomy_id | 「term_taxonomy」テーブルの「term_taxonomy_id」 |
各テーブルの相関関係
WordPress Codexに視覚的に表したわかりやすい図があります。
前述の通り、例えば投稿基本情報の「wp_posts」テーブルとターム情報「wp_terms」テーブルは別々に管理されているのですが、一意のID（プライマリーキー）で関連付けがされています。
これが「リレーショナルデータベース」という訳です。フムフム。
