単一の「正しい」方法があると言う人には懐疑的であるべきです。正しい方法は状況によって異なります。CPTインフラストラクチャを使用することには、多くの注目すべき利点があります。
- ダッシュボードUIは無料で入手できます
- インストールで使用されている可能性のある永続キャッシュプラグインを含む、WPのキャッシュを自動的に利用します。
- 改訂後などの特典を自動的に取得します
WP_Queryクラスにアクセスできます。つまり、理論的には、バギーで脆弱で非効率的なSQLを（少なくとも少なくても）書く必要はありません。- プラグインを配布したり、オープンソース開発用に公開することを計画している場合、開発者は独自のカスタムのものよりもカスタム投稿タイプと関連するAPI関数を使用する方が快適であることがわかります。
CPT APIの問題は、主に「投稿」のメタファーと非常に結婚しているという事実と、メタファーに付随するそのデータ型のすべての側面に起因します。MySQLコマンドラインからを実行しDESCRIBE wp_postsます。WPは、コンテンツにタイトルがあり、（単一の）作成者がいること、作成日と最終編集日のみを追跡する必要があること、インデックスなしpost_contentなどのためにスペースが必要であることなどを想定しています。一部のコンテンツには適していますが、必ずしも他のコンテンツには適していません。あなたはすでにいくつかの潜在的な問題の方向に身振りしました：
そのルートに行くと、それが物事を「トリッキー」にする場合、cptごとに余分なフィールドに必要なポストメタフィールドの数
wp_postsCPT APIを介してスキーマを拡張するには、ポストメタと分類法の2つの方法があります。Postmetaはインデックス付けされていないキーと値のペアであり、さまざまなデータを格納するのに最適ですが、複雑な検索を行うために最適化されていません。この点で分類法はやや柔軟性がありますが、非常に複雑なルックアップがある場合は、潜在的にコストのかかるサブクエリがたくさん発生します。（meta_queryおよびtax_query引数とそのクエリコンストラクタクラスは非常に便利で便利です。）
あなたが示唆するように、時折のレポートの場合にこれらの種類の「半複雑なリレーショナルフィルタ」を実行するだけでよいなら、このアーキテクチャはおそらくあなたにとって大丈夫です。フィルターをユーザーに公開し始めるJOINと、多くの複雑なsとサブクエリを常に実行しなければならず、物事はすぐに手に負えなくなります。
特に多対多の関係がある場合、関係を最適に管理する方法
多対多の関係は、WP開発者コミュニティの長年のこだわりのポイントです（https://core.trac.wordpress.org/ticket/14513を参照）。分類項目をpost_idにマッピングすることにより、カスタムテーブルを使用せずに偽造できます（たとえば、P3にタグ「Y-P3」があると言うことで「P3にはYとP5の関係がある」と言うことができます） （そして非効率的）非常に迅速に。また、CPTをリンクする独自のリレーションシップテーブルを作成することを検討することもできます。CPTの利点は引き続き得られ、DBテーブルは1つしか作成できません。このメソッドの適切に実行されたバージョンについては、Posts 2 Postsプラグインを参照してください：https : //wordpress.org/extend/plugins/posts-to-posts/
したがって、最終的には次の要素に基づいて決定する必要があります。
- 保存するデータの種類-それらはどの程度「投稿」されているか
- 必要となるクエリの種類-複雑さ
- スケール-目的のスキーマの複雑さ、オブジェクトの合計数、予想するユーザー数
答えが次のとおりである場合：非常に役立たず、複雑すぎず、超巨大に拡張する必要がない場合は、CPTを使用します。それ以外の場合は、独自のテーブルを検討してください。