WordPressのデータ構造は非常にシンプルです。
主に投稿（post)、ターム（term）、コメント（comment）、ユーザ（user）の4つで構成されています。
投稿タイプとタクソノミー
投稿には、デフォルトで用意されている「投稿」「固定ページ」および、カスタマイズによって追加されるカスタム投稿があります。
これら投稿の種類を「投稿タイプ」と呼びます。
※用語が重複しているのでややこしいですが、以下単に「投稿」という場合には、固定ページやカスタム投稿を含めた投稿データを指します。
投稿タイプは、register_post_type() 関数によって追加することができます（initアクションにフックして実行する必要があります）が、
Custom Post Type UIなどのプラグインを利用する方法が簡便です。
タームは、投稿に紐付き、投稿をグルーピングするためのマスタデータです。
タームには、デフォルトで用意されている「カテゴリー」「タグ」の他、カスタマイズによって自由に追加できます。
これらタームの種類のことを、「タクソノミー」と呼びます。
WordPress以外では馴染みのない用語のため直感的にわかりにくいですが、個々のカテゴリーやタグが「タームであり、「カテゴリー」「タグ」といった分類の種別が「タクソノミー」です。
「カテゴリー」というタクソノミーの中に「お知らせ」や「コラム」といったタームがある。
「都道府県」というタクソノミーの中に「東京都」や「大阪府」というタームがある。
といった表現ができます。
タクソノミーも、同様にregister_taxonomy() によって追加できる他、Custom Post Type UIなどのプラグインによっても追加できます。
また、投稿、タームともに、階層構造（親子関係）を持つことができます。
デフォルトの投稿は階層構造を持たず、固定ページは階層構造を持っています。カスタム投稿については、投稿タイプのプロパティ（hierarchical）によります。
WordPressのテーブル構造
投稿データは、wp_posts テーブルに保存されます（テーブル接頭辞がデフォルトのwp_の場合。以下同じ）。
このテーブルは、登録IDやタイトルや本文、スラッグのほか、投稿タイプ（post_type）や親投稿（post_parent）を持っています。また、投稿者（author）に、ユーザテーブルのキーを持っています。
投稿のカスタムフィールドや、いくつかの付随情報は、wp_postmetaテーブルに保存されます。
これは、投稿のIDと、キー（meta_key）と値（meta_value）をレコードにもつテーブルです。つまり1投稿の1フィールドが1レコードになります。
自由にカスタムフィールドを追加できるというWordPressの特性上、どうしてもこうなるのでしょうが、結果としてカスタムフィールドを使った検索はインデックスが利かず、また全てのカスタムフィールド値はbigtext型となるため、検索が低速になりがちです。
タームは、wp_terms テーブルに保存されます。
ID、スラッグ、名称からなるシンプルなマスタデータです。
タームがどのタクソノミーに属するかは、wp_term_taxonomy という別のテーブルに保存されます。このテーブルは、タームのIDとタクソノミー名の文字列を持っています。
つまりデータ構造上は、ひとつのタームが複数のタクソノミーに属することができるわけですが、管理画面からそのようなデータを作る術はなく、なぜこのようになっているのかは謎です（wp_termsに持たせればよいのに・・・）。
投稿とタームの紐づけは、wp_term_relationship テーブルに保存されています。投稿のIDとタームのIDをレコードにもつ典型的なリレーションテーブルですが、タームのIDは wp_terms の主キーではなく、wp_term_taxonomy の主キーであることに注意してください（手でテーブルを操作しない限り、両者の不一致は見たことがありませんが）。
ちなみに投稿のwp_postmetaにあたる拡張テーブルは、今のところタームにはありません。
タームにカスタムフィールドを追加するいくつかのプラグインは、wp_postmetaを流用しています。
タームのカスタムフィールドをデフォルトでフォローしようという動きもあるので、今後はwp_termmetaができるかもしれません。また、そのようなテーブルを作ってしまうプラグインも中にはあります。
コメントデータは wp_comments と wp_commentmeta 、ユーザデータは wp_users と wp_usermeta にそれぞれ保存されています。
その他、wp_options というテーブルもあります。
いわゆるシステム定数にあたる設定（config）データを保持するためのテーブルで、キーと値のセットをレコードに持っています。
WordPressがデフォルトで作成するデータのほか、プラグインが設定データを保存するテーブルとしても使用されます。
原則的には、WordPressにこれ以外のテーブルを作ることは、推奨されません。
多くのプラグインは、データの保存先として、これらのテーブルのいずれかを流用しています。例えば、Advanced Custom Fieldsプラグインのカスタムフィールドの設定データは、wp_posts テーブルに保存されています。
しかし、パフォーマンスやセキュリティの観点から、敢えて独自のテーブルを作るべきケースもあるでしょう。
例えば、メールフォームから送信された情報をデータベースに保存する場合、wp_posts テーブルを利用する方法も考えられます。
しかし、wp_postsのデータは様々な投稿関連のクラスから参照されるため、セキュリティの観点から必ずしも適切とはいえません。
このような場合には、専用のテーブルを作成して、データを保存する方が、より安全性が高いといえるでしょう。
