web-dev-qa-db-ja.com

プラグイン用に独自のテーブルを作成するのは悪い習慣ですか？

私のプラグインの設定を保存したいのであれば、それはかなり簡単で簡単です。

それではもう少しデータベースに保存したいと思います。

ファイル名、およびそのファイルにのみ適用される他の3つの値。そしてそれらの値を持つファイルはたくさんあります。組み込みのデータベースメソッドを使ってある種のサブアレイを保存することは可能ですか？どうやってそれらを削除しソートすることができますか？

pluginsdatabase
10
Badr Hari

私はそれ以外の知識のあるユーザーに賛成できないことはめったにありませんが、この場合私はそれを助けることができません。私の意見では、非コアデータベーステーブルの使用法自体を悪い習慣と呼ぶのは単なる間違っています。

コアテーブルを使用するか独自のテーブルを追加するかは、いくつかの要因によって決まります。

クエリの実行時間はテーブルのサイズによって異なります。したがって、大量のデータを保存することを計画している場合は、この1種類の特定のデータセットだけに対応する別のテーブルを使用することが、必然的により効率的な解決策になります。

これらの特定のデータセットと一緒にたくさんの通常の投稿やCPTを保存すると、wp_postsだけでなくwp_postmetaも急増する可能性があります。

私にとっては、この選択は最終的にはデータがどの程度「Posty」であるかによって異なります。それは著者、コメント、改訂、抜粋などをサポートするべきですか？もしそうなら、私はCPTやコア機能と行きます。そうでない場合は、リソースの使用と効率のために別々のテーブルを使います。

ユージーンの概念が正しければ、既存のよく書かれたプラグインのどれも独自のテーブルを追加しませんでしたが、幸いにもそうではありません。

12
Johannes Pille

WPコアDBテーブルを使用するのがベストプラクティスです

  1. コアDBテーブルを使用すると、データの移植性が向上します、バックアップが容易になります。コアエクスポーター/インポーターと無数のバックアッププラグインによって処理されるためです。
  2. コアDBテーブルを使用すると、データの操作がより簡単で安全になります。クエリ、追加、変更、削除、および関連するさまざまなWordPressコア関数への直感的なアクセスができるためです。特に非常に強力な $wpdb class を使用して、DBデータをサニタイズします。
  3. コアDBテーブルを使用すると、データの分類とストレージのベストプラクティスが促進/促進されます（プラグインオプションをwp_optionsの単一行に配列として格納し、プラグイン開発者にデータのタイプを慎重に検討させる作成/保存されている-CPTですか？分類法ですか？メタ投稿ですか？
  4. コアDBテーブルを使用する場合、プラグインが残骸を残す可能性は低くなります.

WordPressはプラグインがデータベースにテーブルを追加する手段を提供します

ただし、個別のDBテーブルが必要なユースケースの場合、 WordPressデータベースにカスタムテーブルを追加するためにWordPressが提供するメソッドを使用してください =、特に強力な$wpdbクラスを利用できるようにします。このCodexエントリがリストする情報/警告に注意してください。

  • セットアップ情報-ユーザーが最初にプラグインをセットアップするときに入力されるユーザー選択項目で、それ以上大きくなる傾向はありません（たとえば、タグ関連のプラグインでは、サイドバーのタグクラウドの形式）。 セットアップ情報は、通常WordPressオプションメカニズムを使用して保存されます。

  • データ-ユーザーがプラグインを使用し続けるときに追加される情報。通常、投稿、カテゴリ、アップロード、その他のWordPressコンポーネントに関連する拡張情報です（たとえば、統計関連のプラグインでは、さまざまなページビュー、リファラー、およびサイトの各投稿に関連付けられたその他の統計）。データは、作成する必要のある別のMySQLテーブルに保存できます。 ただし、まったく新しいテーブルを使用する前に、プラグインのデータをWordPressのポストメタ（別名カスタムフィールド）に保存できるかどうかを検討してください。ポストメタが推奨される方法です。可能な場合/実用的な場合に使用してください。

したがって、次のことを結論付けることができます。

  1. コアWPテーブルにデータ（セットアップ、またはユーザー生成）を保存することはベストプラクティスです
  2. カスタムDBテーブルを作成するための有効なユースケースがあります。したがって、カスタムDBテーブルの作成はinherentの悪い習慣とは見なされません
  3. カスタムDBテーブルを作成するとき、WordPressはベストプラクティスの実装を提供します
5
Chip Bennett

あなたのデータがWordPressのポストモデルよりも複雑であるなら、非コアデータベーステーブルは必須です、そしてそれは巨大になるでしょう、そしてそれは検索されるメタ詳細をたくさん持っています。

WordPressがポストメタとして使用するEAV形式は、複数基準検索には向いていません。

メタを多数のエントリに分割すると、投稿メタテーブルには投稿ごとに多数のエントリが含まれるようになり、メタを介して任意の投稿を検索するのははるかに遅くなります。

すべてのメタを配列に直列化して格納し、それをpost metaに1つのエントリとして含めると、今度はそのmeta内でテキスト検索のみを実行することになり、SQLクエリで直接比較演算子を使用できなくなります。

あなたのプラグインが何千ものエントリと関連するメタを持つことにならないのであれば、大きな問題ではありません。

しかし、あなたのプラグインが大きなことをするつもりなら、大きな問題です。

あなたの状況、独立したエントリとしてのファイル名、およびそのエントリに添付された3つのメタデータエントリはそれほど大きくはありません。あなたはそれのためにワードプレスの投稿テーブルとメタテーブルを使うことができます。

しかし、人々がこれらの3つのメタを特に一緒に検索するのであれば、それから私はあなたが別々のテーブルを設定することをお勧めします。

このフォーマットでは、たった1つのエントリを持つ1つのテーブル（すべてのメタも含まれています）で問題なく、すぐにクエリが実行されます。

ちなみに、WordPressのテーブルを使用していて、クエリキャッシングも使用している場合、ユーザーのデータ検索は時間の経過とともにキャッシュされ、負荷が軽減されます。しかし、それは別々のテーブルを作成するほど賢明ではないでしょう。

1
unity100
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;
    }

}
  • クラスの名前は元のものです。名前を変更してください。
  • 関数php add：add_action（ 'init'、array（ 'TMM'、 'register'）、1）;
  • そしてajaxを追加します。add_action（ 'wp_ajax_change_options'、array（ 'TMM'、 'change_options'））;
  • 必要な場所でオプションを取得するには（たとえば）、次のようにします。$ logo_img = TMM :: get_option（ 'logo_img'）;
  • ネイティブのワードプレス方法であなたのオプションを保存するためにそれを使ってください
0
realmag777

ファイルをメディアライブラリにアップロードできます。メディアライブラリの各項目はwp_postsテーブルに格納されています。つまり、各ファイルはメタデータを持つことができます。 メタデータAPI を使用すると、各ファイルごとに必要なだけの情報をwp_postmetaテーブルに保存できます。

プラグイン用に独自のテーブルを作成するのは悪い習慣ですか？

はい、コア機能を代わりに使用できる場合は、独自のテーブルを作成することはお勧めできません。

0
Eugene Manuilov