問題タブ [cascade]

DepartmentID 列を持つ Companies というテーブルがあるとします。EmployeeID 列を持つ Departaments テーブルもあります。もちろん、Employee テーブルもあります。問題は、会社を削除したいので、最初にすべての部門のすべての従業員を削除し、次に会社内のすべての部門を削除する必要があることです。カスケード削除はオプションではないため、ネストされたトランザクションを使用したいと考えています。私はSQLが初めてなので、助けていただければ幸いです。

SQL Serverで外部キーを設定する場合、どのような状況で削除または更新時に外部キーをカスケードする必要がありますか。また、その背後にある理由は何ですか。

これはおそらく他のデータベースにも当てはまります。

私は何よりも、各シナリオの具体的な例を探しています。できれば、それらをうまく使用した人からの例を探しています。

私は非常に基本的/愚かな質問をしているように感じますが、この方向で何かを見たり、読んだり、聞いたりしたことはありません.

テーブルusers(userId, name)とテーブルPreferences(id, userId, language) があるとします。この例は簡単ですが、複数レベルのリレーションとより多くのテーブルがある状況に拡張できます。
UI がユーザーを削除するように要求したとき、最初にその設定も削除されるという警告を表示したいと思います。ある時点でデータベースが拡張され、テーブルと関係が追加されたが、ソフトウェアがそれに応じて適応されなかった (クライアントが更新されなかった) 場合、一般的なメッセージが表示されます。

どうすればこれを実装できますか? UI はデータ構造全体を認識できないため、依存するすべてのレコードを手動で削除するためにすべての関係をたどる必要はありません。

これには制約があると思います。
制約は最初はアクションではないため、UI でキャッチできるエラーがスローされます。UI が確認を受け取った後、制約はカスケードになります。

なんというか、全部ズレてる気がする..

データベース内のいくつかのテーブルに対してカスケード削除を実行したいのですが、何かを削除するときに失敗した場合にどうなるかについて興味があります。すべてがロールバックされますか？

私は顧客データでいっぱいのデータベースを持っています。大きすぎて操作が面倒なので、顧客の10％までスリム化したいので、開発には十分です。私は非常に多くのテーブルを持っていますが、特にこれは1回限りの取引であるため、「ONDELETECASCADE」ですべてを変更したくありません。

最初にテーブルを設定せずに、すべてのテーブルをカスケードする削除操作を実行できますか？そうでない場合、私の最善の選択肢は何ですか？

他のエンティティ [質問] のコレクションを含む 1 つのエンティティ [プロジェクト] があります。

「all-delete-orphan」のカスケード属性を使用して関係をマップしました。

私の DB では、リレーションは質問テーブルの project_id (FK) フィールドにマップされています。プロジェクトのない質問は必要ないため、このフィールドを null にすることはできません。

私がそうsession.delete(project)すると、それはできないという例外がスローproject_idされますが、そのフィールドへnullの制約を削除すると、削除はうまくいきます。not-null

誰でもこれを解決する方法を知っていますか?

テーブルの名前を変更し、そのテーブルのすべての制約を外部キー関係で削除して、それらをすべてバックアップすることに成功しました。ただし、現在、PK_tblFoo が複数の場所に存在するポイントにいます (テーブルを別の DB に転送するとき)。テーブルの名前を変更しても、主キーの名前は変更されません。

主キーの名前をカスケードするにはどうすればよいですか? テーブルの名前を変更しました。この部分を理解する必要があります。

2 つの主キーを 1 つにマージし、影響を受けるすべての関係をカスケード更新する方法はありますか? シナリオは次のとおりです。

顧客 (idCustomer int PK、Company varchar(50) など)

CustomerContacts (idCustomerContact int PK、idCustomer int FK、Name varchar(50) など)

CustomerNotes (idCustomerNote int PK、idCustomer int FK、メモ テキストなど)

場合によっては、顧客を 1 つに統合する必要があります。たとえば、ID が 1 の顧客と ID が 2 の別の顧客がいるとします。両方をマージして、2 だったものをすべて 1 にします。影響を受けるすべてのテーブルを 1 つずつ更新するスクリプトを作成できることはわかっています。 1 つですが、カスケード ルールを使用することで、より将来性のあるものにしたいので、新しい関係が追加されるたびにスクリプトを更新する必要はありません。

何か案は？

これらの機能が何をするのか、そしていつそれらを使用するのが適切であるのかについて、誰かが明確な説明/例を提供できますか？

複製: SQL Server でカスケードを使用する場合と理由は?

私はいつも DELETE CASCADE を使用するのが怖くてできませんでしたが、自信がつくにつれて (怠け者:D)、それがどれほど悪いことなのか、使用するのがベスト プラクティスなのか、それとも使用を避けてクリーンアップするべきなのかを考えています。外部キーなどは昔ながらの方法 (ストアド プロシージャを使用) ですか?