ワークフロー アプリケーションのデータ モデルとは? 現在、SQL Server 2000 でエンティティ属性値ベースのモデルを使用しており、ユーザーは (asp.net で) 動的フォームを作成できますが、データが大きくなるにつれてパフォーマンスが低下し、レポートを生成するのが難しくなり、レポートが多すぎるとさらに悪化します。ユーザーは同時にデータを照会します (EAV)。
3 に答える
お気づきかもしれませんが、EAV モデルの問題は、テーブルが非常に大きくなり、クエリが非常に複雑になることです。たとえば、EAV ベースのクエリでは通常、同じデータを取得するためだけに多くのサブクエリが必要になりますが、従来の構造のテーブルを使用している場合は簡単に選択できます。
残念ながら、従来の構造のリレーショナル モデルに移行すると同時に、古いフォームを変更できるようにすることは非常に困難です。
したがって、私の提案は、確立されたフォームの変更を閉じ、そのデータを標準の正規化されたテーブルに移動することを検討することです。たとえば、変更される可能性が低い (または、アプリを変更することで変更を管理できる) 一連の配送フォームがある場合は、固定テーブルを作成して、既存のデータをコピーすることができます。あなたのEAVテーブル。これにより、A) レポートを実行する能力が向上し、B) 既存の EAV テーブルのデータ量が削減され、C) 同時ユーザーをサポートする能力が向上し、データにより適切なインデックスを構築できるため、パフォーマンスが向上します。
簡単に言うと、動的 EAV ベースのシステムは、ユーザーのニーズを収集する方法 (フォームを作成することで教えてくれます) であり、永続的なストレージではないと考えてください。フォームが最終的なフォームに進化するにつれて、上記の利点を得るために固定テーブルに移行します。
最後に一つだけ。これらすべてが不可能な場合、EAV テーブルを複数のカテゴリ固有のテーブルに分割することを検討しましたか? たとえば、すべての配送フォームを 1 つのテーブルに、人事フォームを 1 番目に配置するなどです。クエリ構造の問題 (サブクエリが必要) は解決しませんが、テーブルを縮小してパフォーマンスを向上させるのに役立ちます。
これがお役に立てば幸いです - 私自身も同様の状況にあったので、あなたの窮状に同情します!
Typically, when your database schema becomes very large and multiple users are trying to access the same information in many different ways, Data Warehousing, is applied in order to reduce major load on the database server. Unlike your traditional schema where you are more than likely using Normalization to keep data integrity, data warehousing is optimized for speed and multiple copies of your data are stored.
データのリレーショナル モデルを使用してみてください。できます。