問題タブ [referential-integrity]

レコードのリストがある場合、これらのレコードを削除する前に、これらの各レコードに外部キー参照があるかどうかを確認する方法はありますか?

例として、借り手のリストと本のリストがある場合、借り手がまだ貸し出し中の本を持っている場合、その借り手をシステムから削除することはできません。(ただし、私の実際のシステムはそれよりもはるかに複雑です。より多くのテーブルがあります。)

貸出中の本を持っている借り手から削除オプションを削除したいと思います (その例で)。

外部キー参照を含むレコードを削除しようとすると、次のようなエラーが発生します。

データベース アクセスに失敗しました: 親行を削除または更新できません: 外部キー制約が失敗しました ( dbname. tablename, CONSTRAINT fkfieldidFOREIGN KEY ( fieldid) REFERENCES tablename( fieldid))

1 つの解決策は、レコードのリスト内の各レコードに、参照可能なテーブルのいずれかに外部キー参照があるかどうかを確認するクエリを作成することです。

ただし、コンテンツ管理システムのテーブルから 100 レコードのリストを表示したい場合、そのリストを表示するために 100 のサブクエリを実行する必要がある場合、明らかに非常に非効率的です!

エンド ユーザーがレコードを削除しようとすると混乱しますが、そのデータは他の場所で「使用中」であるため削除できません。混乱を避けるために、削除するオプションを削除することをお勧めします。

何をするのが最善かについてのアイデアはありますか？ありがとう。

私の同僚は、クライアントの DBA がプロジェクトの Oracle DB スキーマのすべての外部キー制約を削除することを提案したと言いました。当初、私はその決定に同意しませんでした。私は DBA ではなく開発者です。そのため、決定の背後にはいくつかの理由がある可能性があることに後で気付きました。だから私はこの決定の長所と短所を得ようとしています.

プロジェクト情報:

1. Hibernate パーシスタントを使用した Spring アプリケーション。
2. オラクル 10g データベース
3. SQLローダーまたはプレーンJDBCのみを使用するバッチジョブがあります。

これが私の長所と短所のリストです（間違っている場合は修正してください）

長所：

1. アプリケーションの永続化は Hibernate によって管理されるため、外部キーのカスケードは必要ありません。適切なカスケード オプションを使用して Hibernate によって管理されます。

2. Hibernate DELETE アクション (delete cascading オプションを含む) は、主キー レコードを削除する前に外部キー テーブル レコードを削除します (つまり、参照整合性の問題を回避するため)。この動作は、外部キーなしの場合、外部キーの場合、カスケード付きの外部キーの場合と同じです。ただし、外部キーを追加すると、Oracle の削除操作が不必要に遅くなります。

短所

1. Hibernate は、オブジェクト間の関連付けと関連付け内のカスケード操作を管理するためのメカニズムを提供します。しかし、DB が持つ完全な参照整合性ソリューションを提供することは決してありません。

2. SQL ローダーまたはプレーン JDBC のみを使用するバッチ ジョブには、参照整合性が必要です。

皆さん、これについてアドバイスが必要です。あなたの誰かが DBA である場合は、DBA 側の理由を教えてください。

ありがとうございました。

参照整合性の利点を提供し、クエリに SQL 型言語を使用できるだけでなく、データ属性とエンティティ間の関係に関してエンティティを大まかに定義できるデータベースはありますか?

たとえば、アクセス許可、ユーザー、ユーザー グループ、およびロールを持つ RBAC タイプのモデルを考えてみましょう。複雑で柔軟なモデルには、次のルールを含めることができます。

• ロールは 1 つ以上の権限を持つことができ、権限は 1 つ以上のロールに属することができます
• ユーザーは 1 つ以上の権限を持つことができ、権限は 1 つ以上のユーザーに属することができます
• ユーザー グループは 1 つ以上の権限を持つことができ、権限は 1 つ以上のユーザー グループに属することができます
• ユーザーは 1 つ以上のロールを持つことができ、ロールは 1 つ以上のユーザーに属することができます
• ユーザー グループは 1 つ以上の役割を持つことができ、役割は 1 つ以上のユーザー グループに属することができます
• 役割は 1 つ以上の役割を持つことができ、役割は 1 つ以上の役割に属することができます

上記を RDBMS でモデル化するには、多数の交差テーブルを作成する必要があります。理想的には、データベースで定義したいのは、エンティティ自体 (ユーザー、ロールなど) といくつかの必須属性だけです。他のすべては動的になります (つまり、DDL は必要ありません)。たとえば、事前定義されていない新しい属性を持つユーザーを作成できます。データベースは通常の RDBMS のように参照整合性を処理しますが、事前定義されていないエンティティ間の関係を作成することもできます。

上記は、エンティティを格納するテーブルと関係を格納する別のテーブルを作成することにより、RDBMS である程度達成できますが、単純なクエリを実行するために必要な SQL が過度に複雑になり、パフォーマンスに影響を与える可能性もあります。

だから、私はレールが外部キーに関する参照整合性をサポートしていないという事実に出くわし、かなり驚いた。それで、これを管理するための最良の方法は何ですか？参照整合性に対処するための「レール」の方法はありますか？

理想的には、アプリはこれらすべてに対処する必要はありません。dbはする必要があります。私は外国人のようなプラグインを見ていました。この方法にはいくつかの欠点があるのだろうか。これは通常、レールでどのように処理されますか？

エラーが発生しています：

子行を追加または更新できません: 外部キー制約が失敗しました ( mydb/requests, CONSTRAINT requests_ibfk_5FOREIGN KEY ( fixture_id) REFERENCES fixtures( fix_id) ON UPDATE CASCADE ON DELETE CASCADE)

次のテーブル構造があります。

子テーブル (リクエスト) に共有 ID (fixture_id) を持つ親テーブル (フィクスチャ) の fix_id フィールドのレコードを更新すると、上記のエラーが発生します。

この整合性制約が失敗する理由がわかりません。両方のテーブルには、カスケードする必要がある正しいデータが既にありますか?

どんな助けでも大歓迎です。

参照整合性を適用しない理由の 1 つは、パフォーマンスです。Db は関係に対してすべての更新を検証する必要があるため、処理が遅くなるだけですが、強制する場合としない場合のその他の長所と短所は何ですか?

とにかく関係はビジネスロジックレイヤーで維持されるため、dbがそれを行うためにそれらを冗長にするだけです。それについてどう思いますか。

Railsのようなフレームワークは、制約や外部キーのようなものでさえ、データベースから多くのロジックを移動することを奨励してきました-私の意見では。より管理しやすく、変更が簡単なため、より良い結果が得られます。それでも、一部の操作はより簡単で、SQLでのみ可能です。

MongoDB、CassandraなどのnoSQLデータベースの人気の最近の爆発は、データベース開発のベストプラクティスへのアプローチをさらに根本的に変えました。

私の質問：参照データの整合性はもはや必要ではありませんか？

多くの場合、仕事に最適なツールを選択することになりますが、トランザクションを持つことが必須である金融アプリケーションや同様のタイプのアプリを除外し、お金を稼ぐが銀行レベルの整合性を必要としないより一般的なアプリに焦点を当てましょう。

参照データの整合性はどの程度必要ですか？誰かがそれを使用していないときに彼らが持っていたいくつかの問題をリストすることができますか？

より重要なデータにはPostgreSQLのようなデータベースを使用し、重要性は低いが要求の高いデータにはMongoDBを使用するのが賢明な戦略ですか？どのデータが「重要」で何が「非重要」であるかを正確に定義することをどのように提案しますか？

アプリケーションにはバグがあるか、更新時にバグが発生し、適切なテスト スイートを使用しても、数か月または数年後に検出された隠されたバグ、孤立したレコード、どこにも指していないキーなどが生成されます。

Rails はデータベース レベルで参照整合性を強制しませんが、他の場所で説明したいくつかの正当な理由により、そのまま維持されますが、データベースが一貫した状態にあるかどうかを確認できるツールがあると便利です。

モデルは「あるべき」ものを記述しているため、オフライン ツールですべてのデータの整合性を検証することは可能ではないでしょうか。データをバックアップする前に、または単に開発者の睡眠のために定期的に実行できます。

このようなことはありますか？

すべて同じスキーマ定義を持つ多数の MySQL データベースを単一のデータベースに統合したいと考えています。各データベースからのダンプ ファイルがある場合、主キーと外部キーが衝突することなく、それらすべてを同じデータベースにインポートするにはどうすればよいですか?

これを行うためのかなり簡単な方法はありますか?それとも、データを理解し、統合された一連のレコードを「手動で」作成するカスタム コードを作成する必要がありますか?

木を見て森を見ていないのかもしれませんが、次のようになります。

私は XML ドキュメントを「設計」しており、これまでに次のようなものを考え出しました。

つまり、単純な階層構造です。私が今やりたいことは、ある要素から階層内の他の要素への参照を持つことです。各要素に一意の ID がある場合は簡単ですが、そうではありません。これまでのところ、各要素のキーがそのレベル内で一意であることを保証することのみを計画しています (ディレクトリ構造内のファイル名によく似ています)。

つまり、 などの完全修飾キーがあれば、root.foo参照整合性の保証は簡単になります。しかし、冗長な情報を保存することになります (fooのサブ要素であることは既にわかっていrootます。なぜその情報を 2 回保存するのでしょうか?)。

これは本質的に見た目の問題であることを認識しています。最も単純な解決策の 1 つは、おそらく ID を自動割り当てして、それで完了することです。しかし、これはかなり洗練されていない (そして、ファイルを編集するための優れたフロント エンドがない限り、エラーが発生しやすい) ため、より適切な方法でそれを行うことを望んでいました。

これを XML スキーマで実装する方法はありますか?