私は、エンド カスタマーに関する多くの情報を保存する金融サービス製品に取り組んでいます。私たちのクライアントは継続的に新しい属性を追加したいと考えていますが、それは多くの場合、製品のプロセスを駆動するために使用されていません。それらはキャプチャされて表示されますが、他には何もありません。クライアントの操作方法の違いにより、多くの場合、非常に異なる値を保存したいと考えています。それらに対応するために、次の 2 つのソリューションを試しました。
私たちは、両方のソリューションのほとんどの欠点を経験しました。多くの列は、データベースに追加するデータを把握しているという点で安心感を与えてくれますが、お気に入りのゴルフ クラブのように顧客が新しい値を「ただ」保存したい場合、柔軟性がなく高価に見える可能性があります。EAV は、クエリのパフォーマンスの低下、データの制御の喪失、検証の欠如、保守性の問題など、通常の問題をすべて示しています。
では、もっと良いパターンはありますか？
Percona Live MySQL Conference & Expo 2013でこのテーマについてプレゼンテーションを行いました。私のプレゼンテーションはExtensible Data Modelingと呼ばれていました。
あなたの状況では、ユーザー定義属性は SQL クエリで使用されないため (あなたが言うようにキャプチャされて表示されるだけです)、シリアル化された LOBパターンをお勧めします。
これが私のプレゼンテーションの要約です。スライドは自由に利用できます。
ユーザーのカスタマイズをサポートする拡張可能で柔軟なスキーマを設計することは一般的な要件ですが、自分自身を追い詰めるのは簡単です。
拡張可能なデータベース要件の例:
- ユーザーがオンデマンドで新しいフィールドを宣言できるようにするデータベース。
- または、それぞれが異なる属性を持つ多数の製品を含む e コマース カタログ。
- または、カスタム データの拡張機能をサポートするコンテンツ管理プラットフォーム。
これらの要件を満たすために使用するソリューションは非常に複雑で、パフォーマンスはひどいものです。スキーマとスキーマレス データベース設計の間の適切なバランスをどのように見つければよいでしょうか?
Entity-Attribute-Value (EAV) の短所を簡単に説明します。これは問題のある設計であり、内部プラットフォーム効果と呼ばれるアンチパターンの例です。つまり、RDBMS アーキテクチャの上に属性管理システムをモデル化することです。は、列、データ型、および制約を通じて属性を既に提供しています。
次に、開発者の生産性、データの整合性、ストレージの効率性とクエリのパフォーマンス、および拡張性の容易さに関して、代替データ モデリング パターンの長所と短所について説明します。
- クラス テーブルの継承
- シリアル化された BLOB
- 逆索引付け
最後に、pt-online-schema-change などのツールや、スキーマの変更による負担を軽減する MySQL 5.6 の新機能を紹介します。
特定のパターンを指摘できるとは思いませんが、PostgreSQLについて聞いたことがあるかもしれません。
これは、データベースを大量に使用するアプリケーションの開発中に通常発生する多くの多様な問題に対処する傾向があるデータベースです (つまり、CoffeeScript でスクリプトを作成し、JSON を介してデータにアクセスできます)。
彼らはHSTOREと呼ばれる拡張機能を提供しており、すべての問題を解決してくれるようです。HSTORE を使用すると、基本的に、データの任意のハッシュをテーブルに格納できます。それを照会することさえ可能です。