Q&A
テーブル構造とデータの入り具合を提示されないとなんとも言えないと思いますし、WordPressのコードを深く読み込む必要があります。
通常は命名だけでパフォーマンスに影響はないです。ただ、DBを利用するアプリケーション側のアプローチの仕方次第なところはあります。
###前提
WordPressで記事とユーザーに「レベル」を設定しようと思ってます。
###知りたいこと
カスタムフィールドのキーの命名で、次のどちらがよいのか知りたいです。
【統一する】
「custom_field_level」のように統一する。
【区別する】
「post_custom_field_level」と「user_custom_field_level」のように区別する。
テーブルの構造がわからず、こういうことの正しい推測ができません。
どちらが早い、適切だ、管理面で楽だ、などをおしえていただけませんでしょうか。
###自分の推測
管理面では、「custom_field_level」で統一した方が楽だろうとは考えています。
しかし速度面では、統一するとデータベースからWP_Queryで記事を取得するとき、探す対象は記事であってユーザーではないにも関わらず、ユーザーの「custom_field_level」まで探す羽目になってしまうのではないか？などと推測しまして、これを特に不安に思い質問させて頂きました。
どういう命名がいいのか知りたいです。
宜しくお願いいたします。
回答1件
0
ベストアンサー
user_metaとpost_metaはテーブルが違うので
meta_keyが同じだからといって処理量に影響しません
投稿2019/11/28 00:01
総合スコア7819
テーブルですか。なるほど。リンク先をによれば、投稿タイプは同じpost_metaというテーブルになるわけですよね？ということは、別の投稿タイプで同じキーだと問題ありということでしょうか？その場合は別のキーの方が、処理がはやい？とかになりますか？
質問の例と同じですが、投稿タイプAとBがあり、同じ「custom_field_level」というキーで「レベル」の情報を持っていることを想定します。そしてAだけを取得したい場合に、Bの「custom_field_level」まで捜査する羽目になり、処理が遅くなる、などはありますでしょうか？
違う投稿タイプのカスタムフィールドのキー値が同じというのは同じテーブルになるので
多少処理が多くなるかもしれませんが通常で使う範囲ではまあ誤差の範囲です
meta_queryのleft_joinの判定が、いくつかの投稿で一つ多くなるだけで
meta_query自体の処理の重さに比べたら誤差でしかないです
それよりは、キー値がユニークであれば
post_metaテーブルだけで完結できる処理があるかもしれない
ということの方がキー値を同じにしないようにする理由になるかもしれません
詳しくありがとうございます。仰るように別にしたいと思います。また機会がございましたら宜しくお願い致します。
すみません…
>post_metaテーブルだけで完結できる処理
とは？簡単で結構ですのでざっくり例を教えていただけませんでしょうか。
例えばカスタムフィールドで投稿を検索するにあたって
タイトルやコンテンツは必要なくpost_idだけが欲しい場合です
こういうケースは投稿同士を関連づける機能を作ったりした場合に結構発生します
meta_keyがユニークであれば
別のpost_typeのpost_idが混入する可能性を考えなくて良いので
postsテーブルでpost_typeを判定する必要がなくなります
post_statusも無視することになるのでそこは注意が必要です
なるほど！よくわかりました。安心して別の命名にできそうです。どうもありがとうございました。
あなたの回答
tips
プレビュー
