投稿、固定ページともに「カスタムフィールド」があり、メタ情報をお好みで追加できる。DBからみた構造テーブルの数は11個。注目すべきテーブルは5つ。wp_***_posts投稿、固定ページ情報が入っているテーブル。いう属性により切り替わっている。値は主に以下が入っているっぽい。投稿/固定ページのリビジョン情報テーブルのPrimaryKeyは「ID」つまり、上記の情報は種類は違うけどIDはかぶらないはずということ。ものを作成する事ができたりもします。いうメソッドでID指定すると、このテーブルの情報がとれる。いうメソッドで条件指定で複数のPOSTを取得できるメソッドがあるけど、引数で設定するのはテーブルの項目とは一致しない。違うタイプは明示的に指定が必要。(グループ化できそーだけどどこから設定するのか不明)と4つだけ。term_idがPrimaryKeyだけど、使用者としてはslugがkey項目として使う感じ。このテーブルに入っているものでslugは重複したらNG。カテゴリ、タグの区別情報は入っていません。区別情報が入っているのがこのテーブル。テーブル項目は、以下。count"taxonomy"項目には以下の情報がはいっているっぽい。差があるけど、変更はこのテーブルの値を変えるだけで切り替えができるということ。「カスタム投稿タイプ」同様、taxonomyも自作できる機能があるのですが、その情報はここに入ります。wp_***_term_relationshipstaxonomyとpostをひもづけているのが多分このテーブル。テーブル項目は、以下。(多分)wp_***_postmeta画像などのattachmentのID情報、投稿/固定ページで設定できる「カスタムフィールド」の値はこのテーブルに入ります。テーブル項目は、以下。"_thumbnail_id"が入っています。カスタムフィールドの場合は、指定したkeyがそのままmeta_keyにはいります。いう時には「postmetaからIDを取得して、postsから情報抜き出す」ということで可能です。get_post_customというメソッドが用意されています。書いてしまいましたが、データ構造を俯瞰して分かる事としては...こんなこと。値で新しい種類のものが追加される可能性が大きい。key名は、WPがversionアップ(機能追加)してもつけられないであろう名前にしておく方が無難。keyがかぶらなければ。違うpluginで同じkey値を偶然に使っていた場合はチョー怖いね。リビジョンを保持するようにすると、postテーブルに入っちゃうのでレコード数がガンガン増える!リリース前は少なくともリビジョンは外して登録しておいた方が何となくよいよーな気もする。