問題タブ [junction-table]

Object1とjunctionテーブルとObject2があります。Object2は、多くのジャンクションテーブルを持つテーブルですが、それを参照するジャンクションテーブルは1つだけです。テーブルObject1を削除する場合は、ジャンクションテーブルとObject2を削除する必要があります。この状況で外部キーを作成するにはどうすればよいですか？ただし、Object2を削除する場合は、Object1ではなく、ジャンクションテーブルのみを削除する必要があります。SQLServer2008を使用しています。

次の投稿によると、Entity Framework (最初にコード) で多対多の関係を作成しようとしています: MVC と Entity Framework の限られた数の選択肢のためのデータベース設計?

しかし、私はそれを正しく動作させることができず、非常に単純なことを間違った方法で行っていると確信しています. ここに私の試みから持っていない図があります:

ジャンクション テーブルの要点は、リレーションシップに追加のプロパティ Level が必要であるため、コンサルタントとプログラムの間の直接的なリレーションシップだけを使用することはできません。デザイナーに ConsultantProgramLink エンティティを手動で追加し、Program と Consultant にそれぞれ関連付けを追加し、それぞれに FK を追加することを選択して、両方を主キーにしました。しかし、このようにすると、期待どおりに動作しません。

Consultant と Program を直接関連付けていれば、コード内でたとえば Consultant.Programs を参照できたはずです。しかし、それはジャンクション テーブルでは機能しません。これを解決する方法はありますか、それとも常にジャンクション プロパティ (Consultant.ConsultantProgramLink.Programs) を使用する必要がありますか? いずれにせよ、junction プロパティを通過しようとしても役に立ちません。私のコードで Consultant.ConsultantProgramLink を実行できますが、別のドットではナビゲーション プロパティ Programs が表示されません (何らかの理由で単に Programs になったのはなぜですか?最終的にそれらにアクセスできるようになったら、名前を変更できますか?) .

それで、私は何を間違っていますか？コードでドット表記を使用してプロパティにアクセスできないのはなぜですか?

Actors、Films、Actors_Films の 3 つのテーブルを含む DB があります。2 つのテーブルには多対多の関係 (Actors と Films) があり、これはジャンクション テーブル (Actors_Films) を使用してモデル化されています。

Silverlight アプリで EF4 を使用しています。EF モデルを作成しましたが、edmx デザイナーには Actors エンティティと Films エンティティだけが表示されますが、それぞれに他のエンティティへのナビゲーション プロパティがあります (Actors には Films のナビゲーション プロパティがあり、Films には Actors のナビゲーション プロパティがあります)。 .

ドメイン サービスを追加し、プロジェクトをビルドしました。例として俳優を使用して、俳優を循環させるデータフォームと、現在選択されている俳優が出演した映画を表示するデータグリッドを含むビューを追加したいと考えています。ただし、[データ ソース] タブでは、 Actors と Films の 2 つのエンティティを含むドメイン コンテキスト。これらの 2 つのエンティティは実際の列のみを表示しており、ナビゲーション プロパティは表示されていません。

アクター ---ActorID ---ActorName

映画 ---FilmID ---FilmTitle

これは正しいです？ナビゲーション プロパティが表示されるはずだと思いました。

私の実際のアプリケーションはこれよりも複雑ですが、これは実際の問題に焦点を当てるための単純化された例です。

ありがとう

ミック

次の設計パターンが受け入れられるかどうかを判断するのに苦労しています。リレーショナル モデルには、次の要件 (およびその他の要件) があります。

AppA1) アプリケーション ( 、AppB、など) を表すことができなければならずAppC、それぞれが独自の属性セットを持っています。

Internet2) すべてのアプリケーションは、(電子メール、Twitter、Facebook)、 (SMS、MMS など) などのさまざまなチャネルを介して通信できるPhoneため、プログラムとチャネルの間に多対多の関係があります。

3) 多くのプログラムで共有できる事前定義された識別子 (アドレス、電話番号、ログイン アカウント) のセットがあるため、プログラムと識別子の間には多対多の関係があります。

4) 同じ ID で複数のタイプのメッセージを送信でき、プログラムも (多対多) 送信できますが、アプリケーションごとに通信タイプの ID の使用を制限できるようにする必要があります。

基本的に、私が行ったことは、Program、Channel、IdentおよびCommunicationTypeこれらのそれぞれに関する情報を格納する 4 つのテーブルを作成することでした。設計を複雑にする(Program, Channel)、(Program, Identifier)、などのジャンクション テーブルを作成する代わりに、プライマリで構成される単一のテーブルを作成しました。これら 4 つのテーブルのキーに一意の制約を適用し(Program, Channel, Ident, CommunicationType)ます。これで、このテーブルの各レコードが特定の通信にリンクされます。

もちろん、これは私の問題を非常に簡単な方法で解決しますが、正規化の原則に反する場合、これがまったく受け入れられるかどうかを自問しています. どなたかご意見いただけないでしょうか？

編集: 構造的な実装を交換しましたが、問題は同じままです。つまり、SvcRequest レコードを作成する前に、最初に Publication オブジェクトを作成します (まだ存在しない場合)。

「修正」しなければならないデータベースが与えられ、特定の問題について非常に当惑しています。簡単にするために、既に存在する 2 つのテーブル (結果) があります。この 2 つの関係を理解するのにしばらく時間がかかり、最終的に次のような従来のジャンクション テーブルに決定しました。

SvcRequest と SvcProgressLog は、多かれ少なかれ兄弟テーブルであり、どちらも親への参照を含んでいます。この奇妙な階層的な関係を理解するのにしばらく時間がかかりましたが、CRUD 操作を簡単に実行できるように結合する方法が必要なだけです。

ここでのプロセスは次のとおりです。

1. 出版物のサービス依頼が入ります。
2. パブリケーションが存在する場合 --> 対応するパブリケーション レコードを更新します。そうでない場合は、新しいパブリケーションを作成します。その後、Web フォームから取得した情報から SvcRequest レコードを作成します。（ここで助けが必要です）
3. 最後に、存在するがまだログに記録されていないリクエストのログ エントリを作成できます。

次の関係が存在します。

• パブリケーション --> SvcRequest :: 1 --> 多数
• パブリケーション --> SvcProgressLog :: 1 --> 多く
• SvcRequest --> SvcProgressLog :: 多数 --> 多数 (-ish)

いつものように、私は助けと知恵の言葉に大いに感謝しています ;) よろしく

私の質問は、同様に関連するテーブルのために、2 つのジャンクション テーブルを 1 つに結合するという考えについてです。私が何を意味するかを理解するために読んでください。また、これは実際に私が直面している問題であり、したがってこのフォーラムに関連していることにも注意してください。これは幅広い結果をもたらすトピックに過ぎず、さまざまな専門家からもう少し多くの参加を得て、「ベスト プラクティス」のより良い調査を行うことを望んでいます。

このかなり難しいデータベース設計の問題があります。これが、多くの人が貢献し、学ぶことができる wiki のようなものになることを願っています。これを簡単にするために、一連の図を作成し、問題を 1) プロセスと 2) 構造に分解します。

プロセスステップ

1. ドキュメント (Publication) の要求 (DocRequest) が行われます。
2. パブリケーションがまだ存在しない場合は、新しいパブリケーションが作成されます。
3. 実行中のログ (StatusReport) は、要求を満たす進行状況のために保持されます。

注: 特定の発行物に対して、多数の DocRequest および StatusReport (更新を含む) が存在する場合があります。

データベース構造

注: DocRequest テーブルと StatusReport テーブルの両方に、添付の図には示されていない多数のフィールドとサポート テーブルがあります。さらに、特定の発行物は、それらのテーブル内のすべてのレコードが属するマスター レコードです。

-- 現在の実装 --

注: この設計の主な欠点は、新しい DocRequest レコードと StatusReport レコードのいずれかを作成するたびに、Publications テーブル (接合テーブルのように機能する) にも新しいレコードを作成する必要があることですが、これにより新しい Publication も作成されます。結果。これは望ましい動作ではありません。

-- 典型的な実装-- (このタイプの関係の場合)

注: これは問題なく、おそらく理想的ですが、DocRequest テーブルと StatusReport テーブルのいずれかに対する更新を処理し、それらが属するパブリケーションに個別にリンクします。

--私の推奨する実装-- (この特殊なケースの場合)

注: ここで私が思いついたのは、単純にデュアル ジャンクション テーブルを 1 つに結合することでした。この場合、ジャンクション テーブルは、DocRequest または StatusReport で挿入が発生するたびに新しいレコードを取得します。私はおそらくこれをトリガーで処理します。

討論

では、議論を始めましょう。これが悪い考えであると思われる場合は、仲間のデータベース開発者に知らせてください。また、これによりどのような問題が発生する可能性があるかを知りたいです。レコードの正味数は、2 つの別個のジャンクション テーブルの場合と同じである必要があり、実際には、追加の ID 列を節約することで使用するスペースがわずかに少なくなると思います。:)

皆さんの考えを教えてください。多くの方にこの議論に参加していただきたいと思います。乾杯！:)

3 つのテーブル間で多対多のリレーションシップを設定しますが、リレーションシップは一度に 1 つのテーブル (TableA など) と他の 2 つのテーブル (TableB と TableC など) のうちの 1 つのみとなります。つまり、どちらか 1 つのジャンクション テーブルを持つことができます。

TableB_id が null または TableC_id が null であること、または 2 つのジャンクション テーブルであることを確認する制約付き

これら 2 つの可能性のどちらを使用すべきかを判断するための適切な基準は何ですか?

私は自分が書いたMathematicaスクリプトの各実行に関する情報を保存するデータベース（SQLite）の構築に取り組んでいます。スクリプトはいくつかの入力パラメーターを受け取るので、私のDBには、（他の列の中でも）各パラメーターの列を持つテーブルがあります。

入力パラメータの一部は、数値のリストです。これらを保存するための私の最初の考えは、この質問に対する受け入れられた回答で説明されているように、ジャンクションテーブルを使用することです。しかし、私は通常、いくつかの異なる実行に同じリストを使用します。特定のリストがすでにデータベースにあるかどうかを調べるにはどうすればよいですか。そのため、IDを再保存するのではなく、再利用できますか？

コメントで述べられている制約：

• リストの長さに明示的な上限はありませんが、実際には1から約50の範囲です。
• 個別のリストの数は少なく、10のオーダーになります。
• 私は実際に3つのリストパラメータを持っています。それらのうちの2つについては、リスト内の値は非負の倍精度浮動小数点数です。3番目の場合、値はそのような数値のペアです。
• 重複するエントリはありません。（これらはより正確に設定されているため、重複や順序は関係ありません）
• リスト要素をソート順に並べることが簡単にできます。

例：私のテーブルがこのように設定されているとします

スクリプトを実行すると、パラメーターが設定されてから、次のように計算を実行する関数が呼び出されます。

これがスクリプトの最初の実行であると仮定すると、次のコンテンツがDBに挿入されます。

ここまでは順調ですね。ここで、1つの異なるパラメーターを使用してスクリプトを再度実行するとします。

単純な実装では、これにより、データベースに次のものが含まれるようになります。

{.1, .3, .5}しかし、リストがすでにデータベースにあるという事実を検索できるようにしたいので、2回目の実行後、DBには代わりにこれが含まれます。

{.1, .3, .5}リストがテーブルにすでに存在することを見つけるために、どのような種類のクエリを使用できますparam2か？

必要に応じて追加のテーブルを作成することに反対していません。または、より意味のあるジャンクションテーブルを使用する以外のモデルがある場合は、それでも問題ありません。

Book、Section、Content の 3 つのテーブルがあります。セクションとコンテンツの間に多対多の関係を追加したい。Section テーブルと Content テーブルには PageNo 列があります。ページには、多くのコンテンツと多くのセクションが含まれる場合があります。簡単に:

PageNo は、Section テーブルと Content テーブルの両方で一意ではありません。そのため、Sql Server で PageNo の外部キーを追加できません。

次のようなジャンクションテーブルを作成しようとしました：

そして、このジャンクション テーブルに FK を追加しました。したがって、エンティティ フレームワークはジャンクション テーブルを理解でき、SectionId と ContentId で多対多の関係を設定できます。しかし、セクションまたはコンテンツ テーブルのいずれかを挿入する必要があるたびに、SectionContent ジャンクション テーブルにも挿入する必要があります。最初に、ジャンクション テーブルに同じレコードが既に存在するかどうかを確認する必要があります。また、プロジェクトには多くの挿入操作があります。すべての挿入操作を検索する必要があり、追加のクエリを追加してジャンクション テーブルに挿入する必要があります。

また、ページのセクションとコンテンツを取得する必要があります。これは私にとって余分な努力です。

Section テーブルと Content テーブルの間の関係を削除できます。また、PageNo 列で追加の結合クエリを使用できます。しかし、私はエンティティを使いたいです。Section.Contents のようにエンティティの方法で Contents を取得したいし、Content.Sections のように同じ方法で Sections を取得したい。

SQL Server の FK を使用せずに、PageNo 列のセクションとコンテンツの間に多対多の関連付けを追加できますか?

編集: また、上記のジャンクション テーブルを使用する場合、このような SQL クエリを実行する必要がありますね。

2つのテーブルとジャンクションテーブルを持つ古典的なシナリオがあります。たとえば、場所、価格、LocationXPricesとしましょう。

LocationXPricesには、場所と価格のIDのみが含まれているため、それらがどのように関連しているかがわかります。

私たちが得た最善のアプローチは次のとおりです。-ロケーションを多対多で価格にマッピングします-価格を多対多でロケーションにマッピングします-特定のマッピングやLocationsXPricesの.NETオブジェクトはありません。

ジャンクションは、ロケーションが読み取られるときに作成されます。挿入はロケーションと一緒に行われます。

これは、このシナリオで作業するためのベストプラクティスですか？誰かがより良い解決策を提供できますか？それは私にはそれほど自然なことではありません。

ありがとう、モス。