回答:
そうでなければ知識のあるユーザーと意見を異にすることはめったにありませんが、この場合、私はそれを助けることができません。私の意見では、非コアデータベーステーブルの使用法を呼び出すこと自体、悪い習慣自体は単に間違っています。
コアテーブルを使用するか、独自のテーブルを追加するかは、いくつかの要因によって決まります。
クエリの実行時間は、テーブルのサイズによって異なります。したがって、大量のデータを格納することを計画している場合は、この1種類の特定のデータセットだけに対応する別のテーブルが、より効率的なソリューションになります。
あなたは、これらの特定のデータ・セットと一緒に定期的な投稿やCPTSの多くを保存している場合wp_postsだけでなく、としてwp_postmeta急速に成長することができます。
私にとって、この選択は、最終的にはデータがどの程度「ポスティ」であるかに依存します。著者、コメント、改訂、抜粋などをサポートする必要がありますか？その場合は、CPTやコア機能を使用します。そうでない場合は、リソースの使用と効率のために、個別のテーブルを使用します。
Eugeneの概念が正しかった場合、既存の適切に作成されたプラグインはどれも独自のテーブルを追加しませんでしたが、幸いにもそうではありません。
$wpdbクラスを介して、より直感的にアクセスできるからです。wp_options、プラグイン開発者に作成/格納されるデータのタイプを慎重に検討したりするなど、データの分類と格納のベストプラクティスが促進/促進されます。CPT？それは分類法ですか？ポストメタですか？ただし、個別のDBテーブルが必要なユースケースでは、特に強力なクラスを利用できるように、WordPressがカスタムテーブルをWordPressデータベースに追加するために提供しているメソッドを必ず使用してください$wpdb。このCodexエントリリストの情報/警告に注意してください。
セットアップ情報 -ユーザーがプラグインを最初にセットアップするときに入力され、それを大きく上回らない傾向があるユーザー選択（たとえば、タグ関連プラグインでは、ユーザーのタグクラウドの形式に関する選択サイドバー）。セットアップ情報は通常、WordPressオプションメカニズムを使用して保存されます。
データ -ユーザーがプラグインを使用し続けると追加される情報。これは通常、投稿、カテゴリ、アップロード、その他のWordPressコンポーネントに関連する拡張情報です（たとえば、統計関連のプラグイン、さまざまなページビュー、参照元など）。 、およびサイトの各投稿に関連するその他の統計）。データは別のMySQLテーブルに保存でき、作成する必要があります。ただし、まったく新しいテーブルにジャンプする前に、プラグインのデータをWordPressのポストメタ（別名カスタムフィールド）に保存できるかどうかを検討してください。Post Metaが推奨される方法です。可能/実用的なときに使用してください。
したがって、以下を結論付けることができます。
$wpdb（非コアテーブルで使用することは私の回答に含まれていたため、そのクラスを見逃したくありません）
データがWordPressの投稿モデルよりも複雑で、巨大になる場合、および検索されるメタの詳細が多数ある場合は、非コアデータベーステーブルが必須です。
WordPressがポストメタに使用するEAV形式は、多基準検索には適していません。
メタを多数のエントリに分割すると、投稿メタテーブルの投稿ごとに多数のエントリが作成され、メタを介した投稿の検索が非常に遅くなります。
配列にシリアル化されたすべてのメタを格納し、それをポストメタの1つのエントリとしてのみ持つ場合、今度はそのメタ内でテキスト検索のみを実行する必要があり、SQLクエリで直接比較演算子を使用できなくなります。
プラグインに数千のエントリと関連するメタがない場合は、それほど大きな問題ではありません。
ただし、プラグインが大きなことを行う場合は大きな問題になります。
あなたの状況、独立したエントリとしてのファイル名、およびそのエントリに添付された3つのメタデータエントリは、それほど大きくないようです。ワードプレスポストテーブルとメタテーブルを使用できます。
しかし、人々がこれらの3つのメタを特に多く一緒に検索する場合は、個別のテーブルを設定することをお勧めします。
その形式では、すべてのメタも含む1つのエントリを持つ1つのテーブルだけで問題なく、クエリを高速で実行できます。
ちなみに、WordPressテーブルを使用し、クエリキャッシュも使用している場合、ユーザーがデータを検索すると、時間の経過とともにキャッシュされ、負荷が軽減されます。しかし、それは別のテーブルを作成するほど賢明ではありません。
ファイルをメディアライブラリにアップロードできます。メディアライブラリ内の各アイテムは、wp_postsテーブルに格納されます。つまり、各ファイルにメタデータを含めることができます。メタデータAPIwp_postmetaを使用して、テーブル内のファイルごとに必要なだけ情報を保存できます。
プラグイン用に独自のテーブルを作成することは悪い習慣ですか？
はい、代わりにコア機能を使用できる場合は、独自のテーブルを作成することはお勧めできません。
class TMM {
public static $options;
public static function register() {
self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
}
public static function get_option($option) {
return @self::$options[$option];
}
public static function update_option($option, $data) {
self::$options[$option] = $data;
update_option($prefix . 'theme_options', self::$options);
}
//ajax
public static function change_options() {
$action_type = $_REQUEST['type'];
$data = array();
parse_str($_REQUEST['values'], $data);
$data = self::db_quotes_shield($data);
if (!empty($data)) {
foreach ($data as $option => $newvalue) {
if (is_array($newvalue)) {
self::update_option($option, $newvalue);
} else {
$newvalue = stripcslashes($newvalue);
$newvalue = str_replace('\"', '"', $newvalue);
$newvalue = str_replace("\'", "'", $newvalue);
self::update_option($option, $newvalue);
}
}
}
_e('Options have been updated.', TMM_THEME_FOLDER_NAME);
exit;
}
public static function db_quotes_shield($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
if (is_array($value)) {
$data[$key] = self::db_quotes_shield($value);
} else {
$value = stripslashes($value);
$value = str_replace('\"', '"', $value);
$value = str_replace("\'", "'", $value);
$data[$key] = $value;
}
}
}
return $data;
}
}