1

私はPHPとmySQLを使用しています。

ページテーブルとメタテーブルがあります。少しこんな感じです。

ページテーブル

page_id | headline    | content
--------------------------
1       | My headline | My content
2       | Another one | Another text

メタテーブル

id | page_id | meta_key  | meta_value
------------------------------------
1  | 2       | seo_title | Hello world
2  | 2       | price     | 299

このタイプのモデルはEAVと呼ばれていることを読みました。また、パフォーマンスに悪いことも読みました。

私のメタテーブルは、ページに接続されているあらゆる種類の値に対して作成されています。今回は「静的」列のテーブルを作成できません。

質問

  • 各ページに30のメタ値がある300ページの場合、これはどれほど悪いですか？メタテーブルの9000行です。
  • 「動的」データのより良いモデルはありますか？
4

2 に答える 2

2

まず、このモデルを使用すると、データのクエリがはるかに簡単になる場合があります。数日前にここで質問をしましたが、データのクエリを簡単にするためにモデルを1NF形式に変更しなかった理由を提案するユーザーもいました。彼らは私がこのデザインに固執していることに気付いたときだけ、質問に対するいくつかの答えを提供しました。重要なのは、私は幸運にも12列しか合計できないということです。それ以外の場合、テーブルに300列が含まれているとしたら、おそらくユーザーはその問題のクエリを作成する必要はありません。:-)

第二に、データベースによって自然に課せられるいくつかの制限のために、この設計の実装がより簡単な場合があります。値に30文字を超える長い値が含まれている場合meta_keyは、値を短くしてどこかでマッピングを行う必要があります。そうしないと、これが唯一の選択肢になる可能性があります。

最後に、パフォーマンスは非常に重要です。それは本当だ。ただし、一方で、パフォーマンスを向上させるために適用できる特定の手法があります。適切なインデックスの作成、テーブルのパーティション化など。

この場合、テーブルのサイズは非常に小さくなります。したがって、計算量が多く、結合や集計が複雑になるなど、クエリが非常に複雑でない限り、また、アプリケーションが小さな時間の割合に敏感でない場合は、このモデルを採用してもパフォーマンスに影響はないと思います。

最後に、パフォーマンスについてまだあまり心配している場合は、両方のモデルを作成し、ランダムまたは実際のデータを入力し、計画コストを分析して、どちらのモデルがニーズに適しているかを確認することをお勧めします。

于 2012-10-14T14:03:18.677 に答える
1

正規化されたデータベーススキーマは、基本的に一般的なケースに最適化されています。それに比べて、高度に非正規化されたスキーマはパフォーマンスに悪影響を及ぼします。

しかし、これが実際に何を意味するかは、ユースケースによって異なります。どのクエリを実行していますか？したがって、次のことをお勧めします。

  • 完全な永続層が他のすべてからきれいに分離されていることを確認してください。

  • パフォーマンステストを含む自動テストで十分にカバーされていることを確認してください。

  • 最も複雑なパフォーマンスクリティカルなクエリを作成する部分から始めて、現在のソリューションを実装します。このステップにはあまり投資しないでください。たぶんあなたのプロジェクト予算の5％以下の何か。

  • パフォーマンスが十分かどうかを確認します。

  • チェックに失敗した場合は、次のオプションがあります。

    1. マテリアライズドビューを追加する

    2. 仕事により適した代替システムを使用してください。キーバリューストアはあなたが探しているものかもしれません。

    3. または、ハイブリッドアプローチが必要な場合もあります。アプリケーションの一部のEAVと、クエリに適した他のアプローチを使用したデータの複製です。

于 2012-10-14T14:25:11.287 に答える