3

具体的な例を次に示します。

Wordpressは、ユーザー情報（meta）をwp_usermetaというテーブルに格納します。このテーブルで、meta_keyフィールド（例：first_name）とmeta_value（John）を取得します。

ただし、50人ほどのユーザーがいる場合にのみ、テーブルにはすでに約1219レコードがパックされています。

だから、私の質問は：大規模で、パフォーマンスの観点から、すべてのメタをフィールドとして持つテーブル、またはWordPressのようなテーブルがすべてのメタを行として持つ方が良いでしょうか？

どちらの場合も、インデックスは適切に設定されています。新しいメタを追加する必要はほとんどありません。wp_usermetaのようなテーブルは、入力可能なあらゆるタイプのデータに対応するために、テキスト/ロングテキストフィールドタイプ（大きなフットプリント）を使用する必要があることに注意してください。

私の仮定では、WordPressのアプローチは、ユーザーが何を必要としているかわからない場合にのみ有効です。さもないと：

  • フィールドは単一の行に格納されないため、すべてのメタを取得するには、より多くのI/Oが必要です。フィールドは最適化されていません。
  • 大きな欠点（部分インデックスでない限り、ロングテキストのインデックスを作成します...しかし、どのくらいの期間ですか？）に悩まされることなく、meta_valueフィールドにインデックスを作成することはできません。
  • すぐに、データベースは多くの行で乱雑になり、最も正確なメタについても研究を罵倒します
  • 開発者向けはありません。必要なものをすべて取得して適切に表示するために、実際に参加リクエストを行うことはできません。

しかし、私はポイントを逃しているかもしれません。私はデータベースエンジニアではなく、SQLの基本しか知りません。

4

4 に答える 4

7

あなたはEntity-Attribute-Valueについて話している。

- Entity    = User, in your Wordpress Example  
- Attribute = 'First Name', 'Last Name', etc  
- Value     = 'John', 'Smith', etc

このようなスキーマは、特定のエンティティに対して動的な数の属性を許可するのに非常に優れています。属性を追加するためにスキーマを変更する必要はありません。クエリによっては、SQLをまったく変更せずに新しい属性を使用できることがよくあります。

また、探しているエンティティと属性がわかっている場合は、これらの属性値を取得するのに十分な速度です。これは、非常に優れたKey-Value-Pairタイプのセットアップです。

ただし、Valueの内容に基づいてレコードを検索する必要がある場合はあまり良くありません。など、get me all users called 'John Smith'。英語で聞くのは簡単です。'通常の'テーブルに対してコーディングするのは簡単です。first_name = 'John' AND last_name = 'Smith'。しかし、EAVに対してSQLで記述することは簡単ではなく、相対的なパフォーマンスはひどいものです。（すべてのジョン、次にすべてのスミスを取得し、次にそれらを交差させて、両方に一致するエンティティを取得します。）

EAVについてはオンラインで多くのことが言われているので、ここでは詳しく説明しません。ただし、一般的な経験則は次のとおりです。回避できる場合は、おそらく回避する必要があります。

于 2012-06-06T18:12:27.223 に答える
0

平均してwp_usermetaにパックされた名前の数に依存します。

テキストフィールドの検索は非常に遅いことで有名です。インデックスは一般的に高速です。

しかし、一部のデータウェアハウスはすべてのフィールドからのがらくたをインデックスに登録し、Wordpressは同じことをしている可能性があります。

行ではなくフィールドとしてメタに投票します。

おやすみなさい、おやすみなさい。マイク

于 2012-06-06T18:08:28.437 に答える
0

GPL分野の2つの主要なソフトウェアの例は、2つの設計の間にどれほど大きな違いがあるかを示しています。

WordpressとoScommerce

どちらにも欠点と長所があり、どちらもそれぞれの分野で非常に支配的であり、多くのことが彼らと一緒に行われています。しかし、それらの間の基本的かつ最大の違いの1つは、データベーステーブル設計へのアプローチです。もちろん、これらを比較する場合、コードアーキテクチャは検索の速度にも影響しますが、どちらも独自の欠点によって妨げられ、独自の利点によって後押しされるため、本番環境では多かれ少なかれ正確に比較できます。

WordpressはEAVを使用しています。一般データ（異なる投稿タイプの投稿と呼ばれる）はメインエンティティとして保存され、その他はすべて投稿メタテーブルに保存されます。リビジョン、投稿タイプなど、一部の基本データはメインテーブルに保存されますが、残りのほとんどすべてはメタに保存されます。

データの追加、変更、したがって機能に非常に適しています。

ただし、メタテーブルから3〜4個の異なる値を取得し、結果のセットを取得する必要がある複雑なSQL結合を使用して検索してみてください。その鉄の犬。検索するデータによっては、検索が非常に遅くなります。

これが、複雑なデータをホストする必要のある多くのワードプレスプラグインが表示されない理由の1つであり、実際にホストするプラグインは、独自のテーブルを作成する傾向があります。

一方、oScommerceは、ほとんどすべての製品関連データを製品テーブルに保持します。そして、oScommerce modsの大部分は、このテーブルを変更し、それらのフィールドを追加します。products_attributeテーブルがありますが、これもかなりフラットで、メタデザインはありません。製品IDを介して製品にリンクされています。

その結果、非常に昔からの古いスパゲッティコードであるにもかかわらず、oScommerceは、複雑で組み合わされた製品基準を検索する場合でも、驚くほど高速な検索結果を表示します。実際、oScommerceの通常の表示コードのほとんど（製品の詳細ページに表示されるものなど）は、複雑な結合ステートメントで約2〜3個のテーブルからデータをプルする非常に複雑なSQLから取得されます。結合が1つでも比較的単純なSQLを使用すると、wordpressがデータベースでそれを公にできる可能性があります。

したがって、そのかなり明白な結論：EAVは、拡張機能（つまり、ワードプレスの場合）のためにデータを簡単に拡張および変更するのに非常に適しています。フラットで大きなモノリシックテーブルは、複雑なレコードを表すデータベースにはるかに適していて、複数の基準が実行された複雑な検索が行われます。

そのアプリケーションの問題。

于 2014-08-30T20:18:37.300 に答える
-1

私が見たものについては、EAVモデルはパフォーマンスに影響を与えません。null値が必要な場合を除きます。その場合、すべてのtype_metaを保持するテーブルと結合する必要があります。

私はデムズの答えに同意しません。

ユーザーのフルネームを作成する場合は、名前と一致するすべての名前を要求する必要はありません。

そのためには、5番目または6番目のNFを使用する必要があります。

または、次のようなユーザーエンティティのテーブルを作成することもできます。

  • id
  • ユーザー名
  • パスワード
  • 塩

そこに行きます。これが基本であり、すべてのユーザーの「追加」データには、user_metaエンティティとuser_type_metaエンティティが必要です。次に、ユーザーと。

于 2013-06-04T19:36:00.163 に答える