カスタム投稿タイプまたはカスタムテーブル
エンドユーザーが顧客情報を含むフォームを送信できるようにするプラグインを作成中です。送信時に、新しい顧客がリクエストフォームを送信したことを通知されます。アカウントを承認したら、WordPressユーザーアカウントを作成します。
私はこのプラグインの最初の段階にいるので、ユーザー情報を格納するためにカスタムデータベーステーブルを使うべきか、それとも単にカスタム投稿タイプを使って投稿タイプにメタデータを追加するべきかを知りたいです。 ？
アップデート：
うわー、もう投票して！とにかく、私の質問への更新は、私にこのようにそれを言おう…私は今 customer のカスタム投稿タイプを作成しようとした、そして customerのために、 First Name と Last Name を含むメタボックスのみを使用したいと思いました。これを行い、カスタム投稿タイプのサポートオプションをすべて無効にすると、 Title 値がないために投稿が一覧表示される悪夢でした。それは常に Title を "Auto-Generated"に設定するでしょう、そしてそれは私のために働きません。私はこれに遭遇した GREAT Plugin（super-cpt） これはカスタム投稿タイプとメタボックスの作成を簡単にします。
それで、フロントエンドと管理者ダッシュボードが私のために働くように納得させるためにカスタムUIの仕事をたくさんする必要があるので、私はカスタムの投稿タイプが私のために働くことをあまり確信できません。私はカスタムデータテーブルにますます傾いていますが、カスタム投稿タイプのために編集フォームをカスタマイズすることについてのより多くの情報が欲しいです。誰でも共有できるリンクがありますか？
が他の回答にリンクすることを許可されているかどうかわかりませんが、あなたの質問と非常によく似た別の質問があり、承認された回答者は次のことを述べました。
あなたは、唯一の「正しい」方法があると言う誰かに懐疑的であるべきです。正しい方法は状況によって異なります。 CPTインフラストラクチャを使用すると、いくつかの注目すべき利点があります。
- DashboardのUIは無料で手に入ります
- インストールで使用されている可能性がある永続キャッシュプラグインなど、WPのキャッシュを自動的に利用します。
- あなたは自動的にポストリビジョンのようなグッズを手に入れます
- WP_Queryクラスにアクセスできます。つまり、理論上は、バグが多く脆弱で非効率的なSQLを記述する必要はまったくありません。
プラグインを配布する、またはオープンソース開発のために開くことを計画している場合は、開発者が自分のカスタムのものよりもカスタムの投稿タイプおよび関連するAPI関数を使用する方が快適であることがわかります。
出典： こちら
カスタム投稿タイプに関連するメタが1〜2を超える場合、複雑なユーザーがそのカスタムデータに基づいて検索する可能性（または必要性）、次にカスタムテーブル。そうでなければ、メタテーブルで同時に2-3の基準を問い合わせることによって投稿を引っ張るためにメタテーブルで行われる複雑なJOINはサイトを遅くするでしょう。かなり、同時ユーザーに基づいています。 5,000〜10,000のデータエントリがある場合は、クエリ地獄を入力します。
ORが1〜2メタ程度で、メタデータをユーザーが複雑に検索する必要がなく、データを動的に表示する必要がない（ユーザーエクスペリエンスを失うことなくキャッシュできる）場合は、WPの投稿とポストメタを使用します。
ちなみに、邪魔にならないこともできます。すべての投稿エントリをその複雑なメタデータとともにフラットなリレーショナルテーブルに反映させるカスタムテーブルを作成し、検索機能（またはその他の必要な機能）にフックすることができます。このカスタムの「検索キャッシュテーブル」からwp_postsとwp_postmetaの結果セットを読みに行くと、大規模で複雑なデータセットにもwpテーブルを使用できます。しかし、それからあなたはあなたのこのキャッシュテーブルに問題のある問い合わせ操作をそらす必要があるでしょう。
私は、人気のある検索プラグインRelevanssiがそのようなことをすると信じています - 複雑な投稿とポストメタをフラットなリレーショナルテーブルにキャッシュし、そこから検索結果を引き出します。
*修正 - 不正確：relevanssiは高速検索用のデータストアを作成しません。検索品質が向上するだけです。
しかし、実際には、それは私の意見では邪魔にならないところです。データが大きく複雑な場合は、別々のテーブルを使用してください。