カスタム投稿などを使ってみるために、MAMPを使ってwordpressをローカル環境にインストールしました。いろいろいじる際にwordpressがどういう風にデータを管理しているも見てみようと思い、ダッシュボードで値を変えてながら、DBを確認していました。最初は自分でいじりながらメモをしていましたが、wikiですごいまとめがあることに後で気づきました。ここを見てから、後はDBの値を確認するだけで十分勉強になると思います。
データベース構造 - WordPress Codex 日本語版
タクソノミーとは
カスタム投稿タイプ、カスタムタクソノミーのカスタムとはデフォルト用意された投稿タイプ、タクソノミー（分類）以外に更に増やすということ。さらに定義を増やすときに拡張することです。これはDBで確認するとわかりやすいです。新しい定義の文字列を格納してるだけです。聞きなれないかもしれませんが、テーブル名でも使われているので確認しておくとよいです。
DBの設計
postに記事、ページ、それ以外を。taxonomyにカテゴリ、タグ、それ以外を1つテーブルに分けた理由はおそらくアクションに注目したからだと思います。post（投稿）、taxonomy(分類)した結果、出来たものを各テーブルにまとめて管理しようという意図があるのではと推測しました。
wordpressがDBで管理しているもの
wordpressでは主によう管理しているテータは下記の5つでした。
- コメント
- 投稿物（post)
- 投稿物の分類（カテゴリやタグ）
- ユーザー
- wordpressの設定値
テーブルは全部で11個で想像よりかなり少なくて驚きました。把握しやすいものとなっております。外部キーや数値はあまり使わず、ほとんど文字列で色々なデータを1つのカラムで管理していました。値を数値にしたり、テーブルをあまり分けていないところが参考になりました。
各テーブルを実際に見てみる
いくつかのカラムやkeyを挙げていますが、すべて列挙しているわけではありません。私が気になったものだけを抜粋しています。
wp_comments
コメント投稿者のユーザエージェントまで記録しててびっくりしました。どのOSのどのブラウザからコメントを投稿したのかがわかっちゃいます。
wp_commentmeta
postみたいにカスタムフィールドが設定できるのだろうか？
wp_users
カラム名を見てみたところユーザーは基本的な設定値は、メタデータとして他のテーブルに分かれていませんでした。
| カラム | 補足 |
|---|---|
| id | bigint(20)はintとどう違う？ |
| user_login | |
| user_pass | |
| user_nicename | |
| user_email | |
| user_url | ウェブサイト |
| user_registered | 時刻が日本時間ではない。timestampではなくdatetimeの理由とは？ |
| user_activation_key | |
| user_status | |
| display_name | ブログ上の表示名 |
wp_usermeta
ユーザーの詳細データを保持しています。一人の1項目の情報が1レコードになっているため、レコードは必然と多くなります。
カラム
umeta_id
user_id
meta_key
meta_value
下記のユーザー情報はメタデータとして管理されています。
- 名
- 性
- ニックネーム (必須)
- ビジュアルリッチエディターを使用しない（フラグ）
- 管理画面の配色
meta_key一覧
| meta_key | 補足 |
|---|---|
| nickname | |
| first_name | 名 |
| last_name | 性 |
| description | プロフィール情報 |
| rich_editing | ビジュアルエディターを有効にする |
| comment_shortcuts | キーボードショートカットを有効にする（コメントモデレーション用） |
| admin_color | fresh（デフォルト）、lightなど文字列で記録されている。数値を使っていない。 |
| use_ssl | 例：0 |
| show_admin_bar_front | サイトを見るときにツールバーを表示する |
| wp_capabilities | 例：a:1:{s:13:"administrator";b:1;} |
| wp_user_level | 人目のユーザーは10がデフォルト |
| dismissed_wp_pointers | 例：wp360_locks,wp390_widgets,wp410_dfw |
| show_welcome_panel | 例：1 |
| session_tokens | 例：a:1:{s:64:"0a78973a5b7a11c29b03854ec13d5d1178e67cc... |
| wp_dashboard_quick_press_last_post_id | 例：3 |
| wp_user-settings | 例：editor=tinymce |
| wp_user-settings-time | 例：1434456664 |
wp_term_taxonomy
カテゴリ、タグはtaxonomy（分類）としてまとめて管理されています。taxonomyカラムには文字列が入っていました。外部キーが用意されているわけではありません。
| カラム | 補足 |
|---|---|
| taxonomy | category: 記事カテゴリ、link_category: リンクカテゴリ、post_tag: タグ |
| parent | 親がなしの場合は0 |
tarmの親子階層はオブジェクト指向のように、子が親を指し示しています。そのため子は親がどれかが分かるか、親は子がいるのかさえわかりません。親termを削除しても、子termは自動削除されずに残りました。ただし、子termのparentカラムが0（なし）に自動更新されていました。
wp_terms
| カラム | 補足 |
|---|---|
| name | 記事の場合はカテゴリやタグ名が。記事以外のフォーマットを作るとそのフォーマットがtermとして登録される。 |
| term_group | bigint(10) : 0 : 類義語のグルーピング |
wordpressに記事を投稿する際に、その記事のフォーマットを選ぶことができます。未使用のフォーマットを使用すると、これもtermとして自動登録されていきます。
例えば、初めてasideを使用した場合は下記のデータが保持されます。
| name | slug |
|---|---|
| post-format-aside | post-format-aside |
その他
- term_idがユニークのため、termはnameとslugを同じものを作っても以前のものとは新しいものとして作成される。
- parentカラムで親のterm_idを保持しているが、dbを直接いじればタグに親を持たせることはできると思う。
- 親termを削除しても、子termは自動削除されずに残る。ただし、子termのwp_term_taxonomy.parentカラムが0（なし）に自動更新される。
wp_term_relationships
記事(object_id)と結びついているのはterm_idではなく、term_taxnonomy_idです。つまり、カテゴリ名ではなく、そのカテゴリ名の詳細を保持しているレコードのidと結びついています。多対多の関係にある2つのテーブルを繋げるためのこのようなテーブルのことを、中間テーブルと言うらしいです。
wp_posts
- 投稿(post)したものを管理している。そのため、ページ、記事だけでなくアップロードしたメディアも一緒に管理されている。
- 記事は内容を変えて更新するたびにリビジョンが新しいレコードとして登録されるため、修正した分レコードが増えてしまう。 レコードがpostかrevisionかはカラムpost_typeで文字列で保持している。
- post（記事）のpost_content（記事内容）は更新するたびに書き換わる。つまり、いくら更新しても新しく追加されたレコードはrivisionのため、実際に表示される内容を保持しているレコードはidが一番古いpostである。この時、最新のrivisionとpostのpost_contentは同じ内容になる。
wp_postmeta
カスタムフィールドを管理しています。