集中的に照会されるエンティティの動的メタフィールドのデータベース設計
エンティティがユーザー定義のメタ属性の動的セットを持つことができるシステムのデータベース構造を設計しています。メタフィールド（人気度、コンバージョンなど）とスキル値（int、boolean、string）は、管理者が動的に入力します。
データ入力の最後に、管理者はクエリを作成して、メタ値に基づいてエンティティを除外できます。
通常、私は次の構造のメタテーブルを持つというワードプレスのDB構造に従います。
Meta => id, entitiy_id, meta_key, meta_data_type, meta_value
ただし、データのパフォーマンスが高くなることを期待しているため、データのパフォーマンスとクエリ能力について心配しています。 DBMSにmysqlを使用することは言うまでもありません。
これより良い方法がある場合はアドバイスしてください。そうでない場合、この構造を開発する前に注意すべき落とし穴はありますか。
私の知る限り、次の2つの方法があります。
パフォーマンス、単純なクエリ、簡単なプログラミングが必要な場合は、IDを外部キーとして2つ目のテーブルを作成し、格納する各プロパティの列を作成する必要があります。新しい属性についてはデータベーススキーマを変更するにする必要がありますが、主な欠点は何でしょうか。
上記は、データベーススキーマでflexibilityが必要な場合は機能しません（メタプロパティが事前に知られていないか、変更のポイントであるため）codeおよびクエリの複雑さ（フレームワーク/アプリケーションによって異なります）、またパフォーマンスの低下が最初の選択肢と比較されます。パフォーマンスの低下は、ハードウェアを増やすことである程度補うことができますが、コストがかかります。
これは、2つの間のトレードオフです。アプリケーションシナリオを判断し、最も必要なものと絶対に必要なものを決定する必要があります。次に、使用する残りの基準を決定します。
私は上記の両方の方法を見て使用しましたが、SQL /データベースの正規化の観点から見てアンチパターンであっても、2番目の方法の方が効果的だったと言えます（ただし、大量のクエリを実行していませんでした）。ただし、Nice SQLデータベースの設計ではなく、実際に動作するアプリケーションに対して支払いが行われます。
私はこの設計に対して真剣にアドバイスします。エンティティ属性値パターンと呼ばれるデータベースのアンチパターン。
理由については、以下の投稿をご覧ください。
http://karwin.blogspot.com/2009/05/eav-fail.html
http://www.jonathanlevin.co.uk/2008/04/sql-is-in-fact-programming-language.html
より良いアプローチは、あなたが持っている列/属性から始めて、後の段階でそれらを追加することです。
ALTER TABLEステートメントは後で変更を加えるためのものであり、これを「オンライン」で行うためのツールもあります。
http://openarkkit.googlecode.com/svn/trunk/openarkkit/doc/html/Oak-online-alter-table.html
他にできることは、ドキュメントベースのデータベースまたはXMLを使用することです。 XMLドキュメントをMySQLのblob/textファイルに保存することもできますが、この方法では多くのメリットが失われます。