問題タブ [table-per-hierarchy]

GetTableNameメソッドを使用して、指定されたエンティティ クラス タイプのエンティティのテーブル名を調べるコードを見つけました。ただしGetEntitySet、TPH ではテーブル名、したがって一見 EntitySetBase がサブタイプとは異なるため、メソッドは失敗します。15 行目のステートメント"Entity type not found in GetTableName"からmessage で例外をスローします。throw

基本クラスAと派生クラスがある場合B、どの EntitySetBase オブジェクトがタイプ B に対応しているかを調べるにはどうすればよいですか? (レコードが table にあることを確認できるように、 A に関連する EntitySetBase が返されるはずです[dbo].[As]。)

新しいシステム用にまったく新しい 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 ですか?

最後の思い。私のデータベースは非常に頻繁に読み取られ、書き込まれることはほとんどありません。必要に応じて、読み取りの全体をキャッシュすることもできます。

エンティティの 1 つに table-per-hierarchy パターンを実装しましたが、次のようになります。

atm、sube、acikhava エンティティは、基本的に mekan エンティティから派生しています。これらで問題ありません。まあ、私が知りたいのは、これを CRUD ビューにどのように実装すればよいかということです。

これらのエンティティはすべて独自のビューモデルを持ち、mekan 自体はそれ自体で作成することを意図したものではありません。mekan は抽象的なエンティティであるため、ユーザーは atm、sube、または acikhava のみを作成できます。しかし、ビューのモデルを基本エンティティとして設定して続行することはできません。これは、そのように使用することを意図しておらず、エラーをスローするためです。

ここで、この派生エンティティを完全に異なるエンティティとして動作させ、異なるアクションごとに個別のビューを作成する必要がありますか? または、これを達成する別の方法を見つけてください。

ありがとう。

いくつかの基本プロパティを持つ抽象クラスを作成しました。

私のアイテムクラス:

私の OnModelCreating メソッド:

データを保存すると、次のSQLが生成されます:

ShortDescription1 と ShortDescription1 を生成する理由がわかりません

EF を使用していない古いデータベースのバックアップ ファイルがあります。ここで、階層ごとのテーブルを持つ EF コードの最初の流暢な API を使用して新しいデータベースを作成します。そのため、null 不可の識別子列があります。私のバックアップファイルにはディスクリミネーターがありません。そのため、古いバックアップ ファイルを復元しようとすると、識別子列に NULL 値を挿入しようとするため、例外がスローされます。

ディスクリミネーター列に NULL を挿入するときに (EF の助けを借りて) デフォルト値を設定することは可能ですか?

編集: 復元はデータセットを使用して行われます。データセットに値を追加することはできますが、そのようにしたくありません。

EF 6.1 :

多くの pf 継承を持つプロジェクトを開始したばかりです。選択された継承データベース マッピング タイプは、階層ごとのテーブルです。問題は、add-migration を使用して移行を生成しようとすると、次のエラーがスローされることです。

使用されるクラスと構成クラスは次のとおりです。

[ForeignKey] 属性を使用して、派生クラスのナビゲーション プロパティが親抽象クラスで定義された列を使用する必要があることを伝えられることはわかっています。DataAnnotations の使用は避けたいと考えています。なぜこのエラーがスローされるのかわかりません。「バージョン」ナビゲーション プロパティは、SER 構成ではなく AbstractR 構成で定義されています (SER は AbstractR から継承されているため、これも機能するはずです)。

次に、Version プロパティとマッピングを削除すると、SER マッピングで使用される「ChildId」および「ParentId」プロパティで同じ問題が発生します。これは既知の問題ですか？私は何か間違っていますか？

PS : ParentId マッピングは、ChildId マッピングと同じ問題と思われるため、簡単にするために削除されました。

なぜこの種の問題が起こっているのか、誰にも分かりますか?

アップデート

さらに調査した結果、Fluent API は基本クラスのプロパティをマッピングに使用できないことがわかりました。そうですか？これは望ましい動作ですか？DataAnnotations が Fluent API ではなく基本クラスのプロパティを使用できるのはなぜですか? すべての基本クラスのプロパティがすべてのクラス内に挿入されていませんか、それともある種のデコレータ パターンで読み取られていますか?

これは、EF6で機能するようになったこの質問の拡張です。ただし、共有プロパティと非共有プロパティの両方を持つサブクラスがある場合、問題があるようです。

これが私のモデル設定だとしましょう：

データベースでは、同じ列を共有したいBirthCertificate.RegistrationNumberと考えています。そのため、次のようにモデルを設定しています。Licence.LicenceNumberNumber

データベースを生成すると、すべてが期待どおりに見え、機能します。

さて、当面の問題です。Licenceエンティティが有効期限も記録する必要があるとしましょう。だから私は次のようにそれを追加します：

データベースを再生成すると、次のようになります。

さらに、免許証と出生証明書を挿入しようとすると、次の例外が発生します。

タイプ 'System.Data.Entity.Infrastructure.DbUpdateException' の未処理の例外が EntityFramework.dll で発生しました

追加情報: エンティティまたは関連付け間で共有される値は、複数の場所で生成されます。マッピングによって、EntityKey がストアで生成された複数の列に分割されないことを確認します。

データベースが役に立たないため、その例外が発生する理由を理解できます。

私は何を逃したのですか？