問題タブ [referential-integrity]

私のアプリケーションでは、フォームから SQL Server 2005 データベースにデータ (「要求」) を送信し、後で監督者が確認して承認する必要があります。ユーザーは、新しいリクエストを挿入する権限を持っている必要がありますが、既に送信したリクエストを変更することはできません。

テーブルが 1 つの場合、これは簡単です。UPDATE 権限なしで、INSERT 権限のみを付与します。しかし、リクエストは実際には 1 対多の関係で 2 つのテーブルにまたがっています。ユーザーが既存のリクエストに追加の子行を挿入できないようにする必要があります。理想的には、これはデータベース レベルで実施する必要があります。親行と 1 つ以上の子行を同じトランザクションに挿入できるようにしますが、トランザクションがコミットされると、その外部キーを使用して新しい子行が挿入されるのを防ぎます。

これを達成するための最良の方法は何ですか？トリガーなしで「参照整合性」のこの特別なフレーバーを強制する方法はありますか? また、トリガーが唯一の方法である場合、親行が現在のトランザクション内に挿入されたことをどのようにテストできますか?

入力時に特定の値を制限したり、削除の要求時にそれらが削除されないようにするために、参照整合性が必要であることを理解しています。ただし、このメカニズムが常に使用されることを排除する有効なユースケースについては不明です。

これはいくつかのサブ質問に分類されると思います。

1. 参照整合性が適切でないのはいつですか？
2. 外部キーのリストの複数のサブセットおよび/または不完全なサブセットを含むフィールドを持つことは適切ですか？
3. 通常、これはスキーマ構造の設計上の決定ですか、それともインターフェイスの設計上の決定ですか。（または、どちらでもないか、両方である可能性があります）

考え？

データベースの実際のデータを変更する方法でデータベーストリガー/参照整合性ルールが使用されていることを確認しますか（テーブルxの行wを変更すると、テーブルzの行yが変更されます）。

はいの場合、これはインメモリキャッシング（memcacheとその仲間）の人気の高まりとどのように結びついていますか？結局のところ、これらのアクションはデータベース内で発生しますが、正しい状態に反映する（または少なくとも変更された可能性のある状態を無効にする）ために、キャッシングシステムはそれらを認識している必要があります。そのような場合にコールバックが実装されているとは信じがたいです。

誰かがそのようなセットアップの実際の経験/そのようなセットアップを検討してそれを放棄した実際の経験を持っていますか（どちらに行きましたか？キャッシングの場合、どのように整合性を強制しますか？）

Cassandraデータストアで表す必要があるM：M関係について考えてみます。

どのようなM：Mモデリングオプションが利用できますか？それぞれの選択肢について、いつそれを好むのですか？Cassandraを利用したプロジェクトでM：Mモデリングをどのように選択しましたか？

映画分類用のデータベース モデルを作成しようとしています。各映画は、複数の評価システム (BBFC、MPAA など) のそれぞれから単一の分類を持つことができます。これは、暗黙の PK と FK をすべて含む現在の設計です。

問題はMovieClassification、同じシステムからの複数の分類を許可する制約を持つテーブルにありますが、理想的には、特定のシステムからの 0 または 1 つの分類のみを許可する必要があります。

次の要件が与えられた場合、特定のシステムから正確に 0 または 1 つの分類を持つ映画がデータベースの制約によって強制されるように、これを再構築する合理的な方法はありますか?

• 検索できる情報を複製しないでください (つまり、テーブル内で複製するClassificationSystemIdと、MovieClassificationテーブル内の値と同期しなくなる可能性があるため、適切な解決策ではありませんClassification) 。
• 複数の分類システムへの拡張性を維持しますか (つまり、新しい分類システムでは、テーブル構造を変更する必要はありません)?

列にも注意してくださいAdvice。映画を分類にマッピングするたびに、その分類がその映画に与えられた理由をテキストで説明する必要があります。どのデザインもこれをサポートする必要があります。

2つまたは3つのデータベーステーブルを共有するいくつかのアプリケーションを設計しており、他のすべてのテーブルは各アプリから独立しています。共有データベースには主にユーザー情報が含まれており、他のテーブルを共有する必要がある場合もありますが、それが私の本能です。

参照整合性が必要なため、すべてのアプリケーションソリューションに対して1つのデータベースに頼っています。各データベースで同じ情報を最新の状態に保つ必要はありませんが、おそらく最後に10個のテーブルのグループのみが関連情報を持つ100以上のテーブルのデータベース。

アプリケーションごとのデータベースアプローチは、すべてをより整理された状態に保つのに役立ちますが、すべてのデータベースの関連テーブルを最新の状態に保つ方法がわかりません。

したがって、基本的な質問は、両方のアプローチのどちらをお勧めしますか？

ありがとう、

ホルヘ・バルガス。

編集1：

参照整合性を持たないことについて話すとき、それは、テーブルが異なるデータベースにある場合、テーブルに外部キーを含める方法がないためです。アプリケーションごとに少なくとも1つのテーブルには、共有の1つへの外部キーが必要です。テーブル。

編集2：

関連する質問へのリンク：

• クロスデータベース外部キー参照の欠如に関するSQL設計
• 複数のデータベース間で参照整合性を維持する
• 複数のデータベースで参照整合性を回復する方法

2番目のものだけが受け入れられた答えを持っています。まだ何をすべきかを決めていません。

答え：

アプリケーションごとにデータベースを使用し、共有データベースへのクロスデータベース参照を使用し、共有データベースのテーブルを模倣するビューを各データベースに追加し、NHibernateをORMとして使用することにしました。メンバーシップシステムとして、asp.netシステムを使用します。

また、トリガーと論理的削除を使用して、親なしでリヴィン・ラ・ヴィダ・ロカを飛び回るIDの数を最小限に抑えようとします。データベースの同期を維持するために必要な開発作業は多すぎ、見返りは少なすぎます（皆さんが指摘しているように）。だから、私はむしろ孤立したレコードを介して自分の道を戦うことを望みます。

ORMとビューの使用が最初にsvintoによって提案されたので、彼は正しい答えを取得します。

この難しい決断を手伝ってくれたすべての人に感謝します。

エラーのあるクエリの実行時に、SQL Server からメッセージ番号と重大度レベルの情報を取得したいと考えています。

たとえば、ユーザーが別のレコードによって参照されている行を削除しようとし、カスケード関係が「アクションなし」の場合、アプリケーションでエラー メッセージ 547 (「DELETE ステートメントが競合しています。 REFERENCE 制約...") を作成し、ユーザーフレンドリーでローカライズされたメッセージをユーザーに返します。

このようなクエリを SQL Server で直接実行すると、次のメッセージが出力されます。

Asp.Net アプリでは、この情報はイベント ハンドラー パラメーターまたは他の場所で利用できますか?

また、SQL Server メッセージ番号の決定的なリファレンスがどこにあるのか、誰も知らないと思いますか?

私の状況は少し異常かもしれませんが、MySQL データベースに外部キーを定義し、Zend_Db_Tableクラスの参照整合性を強制しています。テーブルは InnoDB ストレージ エンジンを使用します。

$_referenceMapレコードを削除する場合、Zend Framework はテーブル モデルの を介して直接の子を適切に識別し、それらを削除します。ただし、直接の子の子が存在する場合、その外部キーの参照整合性に違反しているというエラーがデータベースから返されます: SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails. Zend_Db_Table_Abstractは、再帰的な方法で参照整合性を強制していないようです。

他の誰かがこれに遭遇しましたか？それはZend Framework のバグですか? 回避策？修正？

アップデート

Nearly a week later and I have no replies to this question. I am thinking I'll have to extend the Zend_Db_Table_Row_Abstract class myself to accomplish this.

3列のテーブルがあります：

PARENT_IDIDは、同じテーブル内でと外部キー関係を持っています。このテーブルは階層をモデル化しています。

場合によってIDは、レコードの名前が変更されることがあります。IDレコードのを更新してから、依存レコードを更新PARENT_IDして新しい を指すようにしたいと考えていますID。

問題は、レコードを更新しようとするとID、整合性が失われ、すぐに失敗することです。

new を使用して新しいレコードを挿入しID、子を更新してから古いレコードを削除できることはわかっていますが、そうすると台無しになるトリガーがたくさん用意されています。

外部キーを一時的に無効にすることなく、子を更新することを約束して親を一時的に更新する方法はありますか (明らかにコミット時に失敗します)。

次のテーブル定義:

複数のカスケード パスがあるため、SQL サーバーでは使用できません。

ON DELETE CASCADEon 列を指定せずに OrderDetails を作成orderして、以下を含むトリガーで注文を削除するときに参照整合性を強制できるかどうかを見てみましょう。

Orders での削除の後にトリガーが起動するため、実行できません (DELETE ステートメントが REFERENCE 制約と競合しました)。

問題はモデルの設計にあり、OrderDetails から Customers への参照は設計が悪いと思います。ただし、それ以外の場合は、異なる顧客に属する注文の OrderDetails を作成することができます。

2 つの質問:

• 最適なモデル設計は?
• それにもかかわらず、トリガーを使用することは可能ですか?

編集: OrderDetails から Customers への参照を削除しましたが、意味がありません。これにより、すべての問題が解決されます。