問題タブ [cascading-deletes]

解決できないように見える問題があります。私はテーブルを持っています：ソフトウェアとテーブル：PC

両方とも相互に多対多の関係があります。つまり、1 台の PC に複数のソフトウェアを含めることができ、1 つのソフトウェアに複数の PC を含めることができます。リンク テーブルは次のとおりです。soft-pc

テーブル soft-pc には、プロダクト キーなどのライセンス情報もあります。

ここでの問題は、ソフトウェアが PC から削除されると、レコードが soft-pc テーブルから削除されることです。ここで、PC からソフトウェアの関連付けを解除し、soft-pc テーブルに保持できるようにしたいと考えています。

それは可能ですか？

最近、データ層に Fluent Nhibernate を使い始めましたが、問題が発生しました。複数の外部キー制約を持つレコードを削除するときはいつでも、そのデータベース エンティティを表すためだけに別のクラスを作成する必要があります。つまり、他の多くのテーブルと関係を持つ User レコードのようなものについては、他の目的には決して使用しない 10 個の異なるクラスのようなものを作成する必要があります。少なくともそれが、物事がどのように機能するかについての私の理解です。

これらのレコードをマップせずにすべて削除する方法はありますか? たとえば、ユーザーの例を使用すると、ユーザーは複数の役割、部門、電子メール アドレス、電話番号、住所などを持つことができます。これらのレコードをすべて削除したいのですが、それらすべてを Nhibernate クラスにマップする必要はありません。

これを実現する UserMapping に設定できるプロパティはありますか?

ありがとう！

ベンダー

(PK) - ID
名

台

(PK) - Id
VendorId - fk - Vendor が削除された場合はカスケード削除)
名前

アイテム

(PK) - Id
VendorId - (fk - ベンダーが削除された場合はカスケード削除)
名前
価格

利用できないアイテム

(PK) - ItemId - (fk -アイテムが削除された場合のカスケード削除)
(PK) - StandId - (fk - スタンドが削除された場合のカスケード削除)

上記のデータベースは、競技場を表しています。

複数のベンダーが存在します (ボブのピザ、トムのタコス...)

ベンダーごとに複数のスタンドが存在します (ボブズ ピザ コンコース A、ボブズ ピザ コンコース B...)

特定のベンダーのすべてのスタンドが同じアイテムを同じ価格で提供するため、アイテムはベンダーによって構成されます。

スタンドは特定のアイテムを使い果たす可能性があるため、UnavailableItems テーブルには、特定のスタンドで利用できなくなった各アイテムのレコードがあります (ItemId と StandId の複合主キーを使用)。

問題：

リストされている最後の外部キー (FK_UnavailableItem_StandId_Stand_Id) を削除ルール: Cascaded で追加するまで、すべて問題なく作成できます。

SQL Compact 3.5 (VS 2010 サーバー エクスプローラーを使用) は、次のエラーを報告します: 参照関係により、許可されていない循環参照が発生します。

UnavailableItem テーブルにレコードがあり、その Vendor が削除された場合、削除が 2 回試行されることを理解しています。

参照アイテムが削除されたため、1 回。

参照されているスタンドが削除されたため、1 回。

しかし、これは私には周期的ではないようです。カスケード削除は 2 つのパス (削除されたスタンドと削除されたアイテム) に分岐し、どちらも削除される同じレコードで終了します... しかし、そこで終了します。その後、カスケード削除の無限ループはありません。何か不足していますか、それとも使用しているツールの制限ですか?

あなたが提供できる助けをありがとう！

ListsとListItemsの間には多対多の関連付けがあります。リストはそのアイテムを認識していますが、ListItemは含まれているリストを認識していません。カスケードはsaveupdateです。

したがって、ListItemエンティティを削除しようとすると、参照整合性が失われているというSQLExceptionが発生します。NHibernateは、リンクテーブルの対応する行を削除せずにListItemを削除しようとします。問題は、参照整合性を壊さずにListItemを削除するようにNHibernateに指示することは可能ですか？

含まれているすべてのリストからアイテムを手動で削除する必要がある場合、どうすれば適切に削除できますか？

アドバイスありがとうございます。

ulu

私は Hibernate を使用しており、親オブジェクトからその子へのカスケード DELETE 操作を数回実装する必要がありました。次の 2 つのオプションを使用しました。

1 つのオプションは、親オブジェクトで getChildren() を公開し、返された子のコレクションに子を追加し、Hibernate が DELETE を自動的にカスケードできるようにすることです。このオプションの欠点は、Hibernate カスケードをサポートするためだけに使用されるにもかかわらず、getChildren() コレクションを公開する必要があることです。

もう 1 つのオプションは、ParentDao.delete(parent) で子を手動で検索して削除することです。このオプションの欠点は、より多くのカスタム コードです。ただし、バッチ削除ステートメントを使用すると、このオプションのパフォーマンスが向上する場合があります。

主にどのようなアプローチを使用しますか? 他の長所と短所はありますか？

実際にカスケードの削除または制限の削除と、カスケードの更新または制限の更新を実際に使用するタイミングを知りたいです。それらを使用したり、データベースに適用したりするのはかなり混乱しています。

次の関連モデルを使用します (1 つのブログ エントリに複数のリビジョンを含めることができます)。

BlogEntryRevision対応するものが削除されたときに、関連するすべての s を削除するように Django に指示するにはどうすればよいBlogEntryですか? デフォルトでは、「反対側」のオブジェクトが削除された場合、オブジェクトを多対多の関係に保つようです。これを行う方法はありますか - できればオーバーライドせずにBlogEntry.delete?

SQLでカスケード削除から値を出力することは可能ですか？

何かのようなもの：

合計3人のメンバーを持つ2つの家族があった場合、次のようになります。

区切り文字リストにカスケード削除されたメンバーを含むファミリごとに1行を生成するソリューションも許容されます。何かのようなもの：

私は単純なコアデータモデルを持っています:

Entity Team (名前、ロゴ) Entity Sport (名前、チームから多くのチームへ)

したがって、スポーツは多くのチームを持つことができます

最初にチームを作成し、次にスポーツを追加または編集して、チームを追加します。チームを削除すると、アプリがクラッシュし始めます。削除された参照を探しているからだと思います。

では、別のエンティティの関係から参照として使用されているエンティティを削除しないように、コア データを介して制限するにはどうすればよいですか。

関係をゼロに設定したくありません。そして、最初にスポーツからチームを削除してから、それを単独で削除したくありません。削除できないことを通知したいだけです。つまり、組み込みのチェッカーを探しています。

私は現在、状態が変化した場合にクラスがオブザーバーを呼び出すことができるアプリケーションをリファクタリングしています。これは、オブザーバーが次の場合に呼び出されることを意味します。

• クラスが変更されたインスタンスのデータ
• クラスの新しいインスタンスが作成されます
• クラスのインスタンスが削除されます

私が心配するのはこの最後のケースです。

私のクラスが本だとします。オブザーバーはBookManagerと呼ばれるクラスに格納されます（BookManagerはすべてのブックのリストも保持します）。これは、これがあることを意味します。

本が削除された場合（リストから削除され、メモリから削除された場合）、オブザーバーは次のように呼び出されます。

問題は、オブザーバーのロジックを制御できないことです。オブザーバーは、プラグイン、顧客の開発者によって作成されたコードによって配信できます。

したがって、このようなコードを書くことはできますが（インスタンスが削除された場合に備えて、リストの次のコードを確実に取得します）：

オブザーバーがリストから他の本も削除する可能性は常にあります。

この場合、リストにTolkienの本が含まれ、その後にCarl Saganの本が続く場合、次のイテレータ（itNext）が無効になるため、Tolkienのすべての本を削除するループがクラッシュする可能性があります。

示されている問題は他の状況でも発生する可能性がありますが、アプリケーションが簡単にクラッシュする可能性があるため、削除の問題が最も深刻です。

アプリケーションで、削除するすべてのインスタンスを最初に取得し、それらを2番目のコンテナーに入れてから、2番目のコンテナーをループしてインスタンスを削除することで問題を解決できますが、常にリスクがあるため、オブザーバーは、削除予定リストに既に含まれている他のインスタンスを明示的に削除します。この2番目のコピーも最新の状態に保つために、明示的なオブザーバーを配置する必要があります。

また、オブザーバーの呼び出し中に（直接または間接的に）コンテナーを反復処理する場合は常に、すべてのアプリケーションコードにリストのコピーを作成するように要求すると、アプリケーションコードの記述がはるかに困難になります。

このような問題を解決するために使用できる[デザイン]パターンはありますか？アプリケーション全体が共有ポインターを使用してインスタンスにアクセスすることを保証できないため、共有ポインターアプローチを使用しないことをお勧めします。