新しいシステム用にまったく新しい DB モデルを設計しています。私の目標は、それを SQL に格納し、Entity Framework によってオブジェクトにマップすることです。複雑なオブジェクト階層をサポートし、DB エンジンによって「適切に」強制されるようにするために、Table-per-Hierarchy パターンを多用しています。
対処方法がわからない次のような状況があります。
リソースと呼ばれる一連のエンティティがあります。各リソースは特定のタイプであり、いくつかの特定の属性が含まれています。
- リソース (抽象クラス、リソース テーブルにマップ)
- リソース テーブルには識別子列があり、主キーとして ResourceId があります
- 次のようなクラス: ServerResource (具体的なクラス、Resource から継承し、1-1 である UrlResources テーブルにマップされ、Resource にマップされます...全体として、約 12 個の他のリソース タイプがあります (数は増え続けています)
- リソースの各タイプには、そのリソースに固有の一意のプロパティのセットがあります)
チェックと呼ばれるエンティティもいくつかあります。各リソースには、多数のチェックが含まれています。ResourceId は Checks テーブルの外部キーです。チェックはもう少し面白いです。リソースの一部またはすべてのタイプに共通のチェック タイプがあります。また、特定の種類のリソースに固有のチェックの種類がいくつかあります。より正確には：
- Check (抽象クラス、Checks テーブルにマップ、CheckId が主キー)
- OutageCheck (ほとんどの種類のリソースでサポートされています)
- SslCertExpirationCheck (1 種類のリソースのみでサポートされています)
- リソース タイプごとに約 3 ～ 4 種類のチェックがあります。そのうちの 1 ～ 2 つはほとんどのリソースで共有され、残りは特定のリソースに合わせてカスタマイズされています
したがって、私の質問は、ERD と Entity Framework の両方でチェックをマップする方法についてです。最も簡単な方法は、リソース タイプとチェック タイプの特定の組み合わせを持つ数十のテーブルを作成することです。IE: ServerOutageCheck、StorageOutageCheck、UrlOutageCheck、UrlSslExpiraitonCheck、ServerLowMemoryCheck など。
これは、管理と保守が少し難しいようです。その共通チェック (例: OutageCheck) に固有の共通チェックを 1 つのテーブル内で共有し、リソース固有のチェック (例: SslExpirationCheck) のみを逸脱できるようにしたいと考えています。これは可能ですか？それとも、テーブル管理の観点から私ができる最善の方法は O^2 ですか?
最後の思い。私のデータベースは非常に頻繁に読み取られ、書き込まれることはほとんどありません。必要に応じて、読み取りの全体をキャッシュすることもできます。