問題タブ [shared-primary-key]

Customer、Broker、Company などのエンティティがあります。これらには異なる属性があり、異なるテーブルにある必要があります。しかし、私たちの場合は連絡先情報 (エンティティ -> 連絡先は 1 対多の関係) のように、共通のものを持つことができます。それを行う最良の方法は何ですか。完璧な設計が存在しない場合、最も重要なことは可能な限り最小限のコードを記述することである場合はどうすればよいでしょうか。

ケース 1: すべてのエンティティに「共通」の auto-inc entityId があります (それらは主キーを共有するため、id=1 の Customer と id=1 の Company を持つことはできません)

ケース 2: 'contact' は、それが参照するエンティティに関する情報を格納します。(顧客、企業、ブローカーは主キーを共有しません)

ケース 3: エンティティごとに 1 つずつ、3 つの連絡先テーブル。

これらのテーブルを接続する方法は他にもありますが、頻繁に発生する問題です。特に解決策が気に入らないので、決定してください。

私は研究室の分析データベースを持っており、バストデータのレイアウトに取り組んでいます。「共有主キー」を使用するための同様の要件に基づくいくつかの提案を見てきましたが、外部キーだけの利点はわかりません。私はPostgreSQLを使用しています：以下にリストされているテーブル

この設計を使用することも、フィールドを分析テーブルから GC テーブルと分光光度計テーブルの両方に移動して、サンプル テーブル、GC テーブル、分光光度計テーブルの間で外部キーを使用することもできます。この設計の唯一の利点は、実際の結果に参加する必要がなく、実行された分析の数または種類に関する情報だけが必要な場合です。ただし、共有された主キー間の参照整合性を確保するための追加の規則、および追加の結合とトリガー (削除カスケードなど) の管理は、マイナーな利点よりも頭痛の種になるようです。私は DBA ではなく科学者なので、何が足りないか教えてください。

更新：共有主キー（私が理解しているように）は、親テーブル（分析）の各値が子テーブルの1つに1回表示されなければならないという追加の制約を持つ1対1の外部キーのようなものです。一度。

Please refer OneToOne between two tables with shared primary key for the original problem.

And my answer in the same thread about a solution in Pure JPA 2.0 way (using EclipseLink Provider).

Now the issue I am facing is that once I switched the JPA provider from EclipseLink to hibernate-entitymanager 3.5.1-Final, Same example is throwing below exception:

Any ideas?

レガシー データベース システムを .NET + Entity Framework 6 (コード ファースト POCO) + PostgreSQL にアップグレードしています。プログラミングを簡単にするために、大きなテーブル (200 以上のフィールド) を複数のエンティティに分割したいと考えています。

EF6 が「テーブル分割」をサポートしていることを知り、うれしく思いました。単一のテーブルを複数のエンティティにマッピングして、フィールドを分割します。

ただし、これを実装しようとしてオンラインで多くのページを読んだところ、複数回分割すると問題があることが確認されました。Entity Framework では、プリンシパル エンティティだけでなく、テーブルにマップされたすべてのエンティティ間のナビゲーション プロパティが必要です。上記の私のシナリオでは、これには 21 個の無意味なナビゲーション プロパティが必要です。わざわざ双方向にするのであれば 42 個です。

参照: http://social.msdn.microsoft.com/Forums/en-US/0f65caae-8a66-431f-aa02-4b2c68f871e9/ef-41-rc-code-first-split-one-table-into-multiple- entities?forum=adodotnetentityframework

参照: EF-Code-First を使用して大きなテーブルを複数の個別の型に分割する方法

共有主キーを持つ複数のテーブルを使用することをお勧めします。私にとってはオプションです。ただし、EF の肥大化した SQL クエリ生成と、複雑なクエリを使用する PostgreSQL の場合によってはでたらめなクエリ オプティマイザを考えると、このオプション (100GB 以上のデータベース) のパフォーマンスに懸念があります。

要約する：

テーブル分割

長所: 最高のクエリ パフォーマンス、データベース レイヤーでの実装が最も速い

短所：私のモデルとOnModelBuilding（）メソッドをがらくたで汚染し、他の開発者を混乱させます

複数のテーブルで主キーを共有

長所: 最もクリーンなモデルとコード、非レガシー データベースに推奨されるソリューション

短所: 実装に余分な作業が必要で、パフォーマンスが低下する可能性があります

私の質問:

1) EF6 は 2 つ以上の分割でテーブル分割を改善しましたか?

2) 考慮していない要因はありますか?

3) 他に選択肢はありますか?

PS [ComplexType] の使用には興味がありません

問題

前の質問のようにテーブル分割を使用して、約 7 個のエンティティで大きなテーブル (200 以上のフィールド) を共有しようとしています。

EF6 では、プライマリ モデルから子モデルへのナビゲーション プロパティだけでなく、すべての子モデル間でのナビゲーション プロパティが必要です (これは最悪です)。

手動ソリューション

これは手動で行うことができます:

スムーズなマッピング:

これは機能します。しかし、これは 7 つ以上のモデルではうまくスケールアップしません。

#1 を改善しようとする

継承 + DRY 原則を通じて改善したいと思います。

しかし、これは「シーケンスに複数の一致する要素が含まれています」という最初のリクエストで失敗します:

改善の試み #2

私はそれらをabstractと宣言できると思ったので、少なくともプログラマーは正しいメンバーを実装することを余儀なくされます(派生クラスごとに再宣言するのはまだ面倒です):

しかし、これは同じエラーが発生したときに失敗します。は？？クラス定義は、「仮想」ではなく「オーバーライド」と宣言されていることを除いて、作業コピーと同一です。E/F が、PropertyInfo.ReflectedType に関係なく、PropertyInfos または何かにインデックスを付けているかのようです。

改善の試み #3

インターフェイスを使用してパターンを強制することもできますが、かなり奇妙に見え始めている各クラスでインターフェイスを宣言する必要があるため、これはあまり好ましくありません。

は？

これは E/F のバグですか? 基本クラスのプロパティを派生クラスのプロパティと同じように扱うのに苦労していますか?

説明が長くなってしまい申し訳ありません、今朝の全調査のまとめです。

共有主キーを使用する 1 対 1 の関係を持つ主キーの生成に問題があります。

コードは次のとおりです。

そしてセカンドクラス：

私は同様の問題を抱えていて、すべてを正しく行ったと思っていましたが、それでも

Pracownik オブジェクトを永続化しようとするとき。

背景については、次の投稿を参照してください。

ナビゲーション プロパティのないエンティティ フレームワークの 1 対 0 または 1 の関係

ForeignKeyクラス内のどのプロパティがナビゲーションプロパティを決定するForeignKeyを保持しているかを示すために使用されるといつも思っていました。

ただし、リンクされた投稿で、これは正しくなく、DeferredData の主キーが Id と呼ばれていたため、実際に必要であることがわかりました。

つまりForeignKey、他のクラスを指すために使用されます。

次に、他の参照のいくつかを変更しました。

しかし、これは失敗しました。これは、クラスForeignKeyの Id を指すために必要であることが判明しました。MemberDataSet

これは、最初の関係が 1 対 0 または 1 であるのに対し、この 2 番目の関係は 1 対多であり、関係の主要な目的が事実上異なるためだと推測しますが、これについての明確さ/優れた記事への参照をいただければ幸いです。何が起こっているのか、ForeignKey が何をしているのかを正確に理解してください。

public int? DeferredDataId { get; set; }また、上記の例で、明示的にリンクされていない方程式にどのように適合するかを明確にするためにも探していましたDeferredData。これが慣習的に一致することをうれしく思いますが、たとえば、別の名前が付けられている場合、これをどのように明示的に伝えることができますか? 属性の使用についてこの話で見たForeignKeyすべての例ですが、上記のすべてのケースでこれが答えになるわけではありません!

モデルには多くの参照があるため、特定の問題を修正するのではなく、問題を理解することを検討しているため、それぞれにどのようなアプローチを取るかを確立する必要があります。

ありがとう。

編集

役立つ他のクラスを追加しました:

新しい行を挿入するときに、主キー列の値を親テーブルから特定の子テーブルに伝達したいと考えています。

説明のために、次の表を作成しました。

RealMaterial新しいマテリアルを挿入するとき、自動的に aまたは a VirtualMaterial(新しい ID を参照)を追加したいと考えています。単一テーブル継承だけでなく、この共有主キー パターンを使用したいことを強調しておきます。

目的のためにトリガーを使用する必要がありますか?

2 つの主キーを持つテーブルを作成し、一度にいくつかのレコードを削除しようとすると、テーブル全体が消去されます。ここに私が試したコードがありますが、なぜそれができるのかわかりません。どんな助けでも大歓迎です。

私の計算では、返されたカウントは 0 ではなく 3 だったはずです。

私は現在、Symfony 2.5 (および Doctrine 2.4.2) を使用して、新しいモジュール/バンドルを簡単にプラグインできるように柔軟でなければならない Web アプリケーションを設計しています。

したがって、抽象クラス（BおよびC）との2つの1対1の関連付けを持つエンティティ（Aとしましょう）があります。将来のモジュールは、2 つの抽象クラスのいずれかを実装します。アソシエーションは 1 対 1 であるため、A のインスタンスの ID がわかっている場合に簡単にアクセスできるように、それらを抽象クラスの ID にしました。

コードは次のようになります。

クラスA:

クラス B:

クラス B と同じなので、クラス C のコードは掲載しません。

私の観点では、それはすべて良いようです。マッピング検証コマンドでも。実際、 を実行するphp app/console doctrine:schema:validateと、スキーマが有効であることがわかります。ただし、このコマンドは自分のスキーマをデータベース内のスキーマと比較しようとしますが、その時点で失敗します。php app/console doctrine:schema:update --dump-sqlまったく同じように失敗します。したがって、スキーマは有効であるが適切に使用できないことが示されるので、かなり恥ずかしいです。

エラー：

[ErrorException]
警告: array_keys() は、パラメーター 1 が配列であることを期待します。null は /vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/Index.php 行 95 で指定されます

InheritanceType および DiscriminatorColumn アノテーションをクラス B および C に追加するとすぐに、エラーが表示されます。つまり、スキーマが有効であることがわかります。

それで、私が何か間違ったことをしているなら、誰にも手がかりがありますか? それとも間違いなく Doctrine のバグですか? 私の現在のソリューションと少なくとも同じくらいの柔軟性をもたらす他のアイデアはありますか?

エリート

編集:ドキュメントによると、所有側は外部キーを持つ側であり、inversedBy 属性を使用する必要があるため、所有側を抽象クラス B および C に変更しました。これらの変更を行っても、スキーマは有効であり、同じエラーが引き続き発生します。

EDIT2: 1 対 1 の関連付けではなくエンティティの ID を保持するために B (および C) に別のフィールドを作成すると、エラーは消えますが、有効なスキーマとは異なります。

編集 3: Doctrine の開発チームのメンバーとチャットしたところ、彼は間違いなくバグのようだと言いました。バグレポートはこちら。