今後のプロジェクトに向けて、データベース設計について大量の調査を行ってきました。
これは古典的な内部プラットフォームの問題であり、クライアントは基本的に無限のカスタマイズと、エンティティにフォームと属性を作成し、エンド ユーザーからそれらの値を収集し、収集した情報をグラフに表示できる機能を望んでいます。
臨床医が患者を監視するために使用するものであり、EAV を使用することさえ考えられる理由は、さまざまな試行ごとにさまざまな情報を収集する必要があるからです. その日食べたものかもしれません。また、血糖値や血圧 (実際には 2 つの数字) である場合もあれば、複数の質問 (今日の痛みは 1 から 10 まで) である場合もあります。エンド クライアントが正確に何を要求するか、または実際に受け入れられる値がどうなるかを進めます。
また、このデータはプログラム全体で一貫してグラフ化され、定期的にではなくより大きなレポートが生成されます。
理想的には、SQL を使用しているため、これを可能な限りハード コードできるようにしたいと考えています。リレーショナル データベースのベスト プラクティスに固執することで、データベース設計とアプリケーション設計の両方が簡素化されます (どちらも私が書いています)。
私たちはいくつかの試行錯誤を行っていますが、私の最初の傾向は、cients からできるだけ多くの情報を取得し、データベース内のテーブルをハードコーディングして、そこから構築することです。属性テーブルと attribue_value テーブルを使用してこれらの属性を収集する必要があることがわかった場合 (ドロップダウンなどの実装が楽しいフォーム ビルダーと一緒に - したがって、ドロップダウン メニュー オプションと検証/必須)、そうすることができます。後で起動します。
私は基本的にすべての関連するスタックオーバーフローの投稿を経験しました。ほとんどの人は、EAV を避け、アプリケーションの要件をよりよく理解し、ある時点で顧客が EAV の実装を本当に必要としている場合は、先に進んでそれを実行すると言います。
ハイブリッドモデル使ったことある人いますか？話し合えますか？
EAV モデルの実装に成功した人はいますか?それについて話し合うことはできますか?
候補のように見えたプロジェクトに EAV を実装しないという同様の決定を下したことはありますか? それはどうなりましたか？
途中で見つけた興味深い読み物を次に示します。
http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ 時系列データの保存、リレーショナルか非か? データベース EAV の長所/短所と代替 案 Entity-Attribute-Value (EAV) の代替案は?