問題タブ [referential-integrity]

私は非常に複雑なXML構成を持つプロジェクトに取り組んできましたが、直面している問題の1つは、XMLの内部整合性を維持することです。

この場合、厳密なXMLスキーマの一貫性を意味するのではなく、使用されるノード間のより高いレベルの関係を意味します。ほとんどの問題は、XMLでエンコードされた情報間の暗黙的なリンク、およびその情報とコードベースとの暗黙的な関係によって引き起こされました。例は次のとおりです。

• コード内の列挙型に暗黙的にリンクされたXMLノードデータ
• 同じ構成内で、それらの間に明示的な関係がなくても（一貫性が必要な情報を共有するという点で）関連しているビジネスオブジェクト
• 実行時にコンパイルおよび解析されるXMLのコード

a）これは頻度を増やす習慣になる可能性があり、b）場合によっては、コンパイル時にチェックされない新しいコーディング言語を暗黙的に作成していることに気づきました。実際、実行されるまでチェックはほとんどありません。

他の誰かが同様のシナリオに直面していますか？問題をより扱いやすくするツールやアプローチはありますか？テクノロジーにとらわれないいくつかの一般的な例が欲しいのですが、私自身の特定の経験は、C＃とプロプライエタリシステムの構成でした。

注：以下に回答がありますが、最終的な回答として自分自身を採用するつもりはありません。

次のように、SQL Server 2005 に 2 つのテーブルがあります。

表 A

• ActionID (PK、int、null 以外)
• ProgressID (一意の識別子、null 以外)
• ReferID (一意の識別子、null 以外)
• フィールド XYZ (varchar(50)、null 以外)
• フィールド MNO (tinyint、null 以外)

表 B

• TrackID (PK、int、null 以外)
• ProgressID (一意の識別子、null 以外)
• ReferID (一意の識別子、null 以外)
• フィールド ABC (varchar(20)、null 以外)
• フィールド EFG (日時、null 以外)

今、私は特定の質問があります：

両方の表のProgressIDは同じエンティティを参照しています。ProgressIDそして、テーブルBに値が存在する場合、テーブルAの 削除ができないように、一体的な関係を確立したいのですが、どうすればいいですか?

誰かが本当に奇妙な問題で私を助けてくれることを願っています。

ユーザーがデバイスを同期すると、次のエラーが発生します。

整合性違反のため、行操作を再適用できません。パブリケーション フィルタを確認します。[テーブル = ASSET_DETAIL、操作 = 挿入/更新、RowGuid = {C92038E4-18EA-EE11-4C9F-2952CDECFCC7}] HRESULT 0x80040E2F (28549)

サーバーに移動してこの行とその親行 (テーブルは資産と呼ばれます) を照会すると、有効で正しいように見えます。完全なフィルター ツリーを調査すると (より適切な説明が必要なため)、すべてのデータが正しいように見えます。

DB で確認できることから、サブスクライバーに送られるべきデータは、DB に設定されている参照整合性制約に従います。また、パブリケーション フィルターにも従います。

サブスクライバーでこの問題が発生する理由はありますか? そして、どうすればこれを解決できますか?

また、デバイスに送信されているデータを正確にログに記録することは可能ですか?

よろしくお願いいたします。

モリスリン

この質問のように、私は PoEAA を読んでいて、MySQL でコミットするまで参照整合性チェックを延期することが可能かどうか疑問に思っていました。

一連の製品と関連製品を同じコミットに挿入したいときに、この問題に遭遇しました。related_productsトランザクション内でも、結合テーブルに挿入しようとすると制約エラーが発生します。

それが役立つ場合は、データベース接続に PHP PDO を使用しています。

ご協力いただければ幸いです。

私が最近考えている興味深いデザインの決定があります。ユーザー名をテーブルに追加していて、重複がないことを確認したいとしましょう。ユーザー名の列はNOT NULL UNIQUEです。次のいずれかが可能です。

1. 挿入する前にデータベースにクエリを実行して、重複する名前がないことを確認するか、または
2. だけINSERTで、データベース エンジンから発生するすべての例外をキャッチします。

私が使用しているDBが制約を適用できると仮定すると、これらの選択肢のそれぞれがどのような状況に適しているのか疑問に思っていました.

既存のアプリケーションを含む 2 つのテーブル (MS SQL Server 2005) があります (インデックスなど以外の DB の変更は許可されていません)。

2 つのテーブルは次のとおりです。

現在、 には制約がありませSubActivitiesんActivityDetailKey。基本的に、ActivityDetail各行には多くの行が存在する可能性がありSubActivities、ユーザーが行を削除して孤立したActivityDetailsままにすることを妨げるものは何もありません。SubActivities

アプリケーションには、これを防ぐ「ソフトロック」がいくつかあるはずでしたが、機能していないため、DB レイヤーにも整合性を向上させたいと考えていました。

しかし、SubActivitiesのActivityDetailKey列がUNIQUEではないため、外部キーを追加できないようです。

ActivityDetails子供がいる場合に行を削除できないようにするにはどうすればよいですか?

ありがとう

編集

複雑で申し訳ありません。SubActivitiesテーブルの実際の名前はTEDetailSubActivitiesです。読みやすいように、質問でそれを変更しました。

とにかく、両方のテーブルの完全なスキーマの要点を次に示します。

https://gist.github.com/840479

助けていただければ幸いです。

MySQLで大規模なデータベースを構築し、SQLYogを使用してテーブル間のすべての関係を作成しました。それはすべてうまくいっていますが、私が構築しているPHPサイトでは、データベースから行を削除する際に問題が発生することがよくあり、参照整合性制約に遭遇することがよくあります。そこで、最初にリンクテーブルからデータを削除するか、フィールドをNULLに設定してみます。私は通常、これをある程度の試行錯誤で機能させることができますが、これを実行する方法や適切なプロセスがないようです。'削除セットNULLまたはカスケード削除設定'を使用する必要がありますか？どちらを使用すればよいかわからないので、他のテーブルの重要なデータが削除されるのではないかと心配しています。

人々はデータベースに関係の制約を設定することさえわざわざしますか？つまり、削除を実行してから、PHPコードでリンクされている他のテーブルを更新するために、いくつかの追加行を書き込む方がはるかに簡単に思えます。

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

最近、Maven HSQL 依存関係をバージョン 1.8.1.2 から org.hsqldb:hsqldb:2.0.0 にアップグレードしました。ただし、HSQLDB を使用したすべてのテストは失敗し、次のような例外がありました。

私はそれをグーグルで検索し、いくつかの答えを見つけましたが、理解するのが難しいと感じました. テストを修正するにはどうすればよいですか? アップグレード前、私のテストは問題なく動作していました。

次の結合テーブルのような状況があります。

重複するグループが入力されないように、テーブルに制約を設定する必要があります。言い換えると：

失敗するはずですが、

それは異なるグループであるため、成功するはずです。

私が考えた2つの方法は次のとおりです。

1. 順序に基づいてマテリアライズ ビューでテーブルをピボットし、ピボット フィールドに一意のキーを配置します。Oracleでは、ピボットルールと32列のインデックス制限の両方のためにグループ内の行数を制限する必要があるため、これは好きではありません（この2番目の問題を回避する方法を考えましたが、それでも）.
2. B_ID の組み合わせで一意のハッシュ値を作成し、それを一意にします。たぶん、私は数学者として十分ではありませんが、B_ID に使用できる値の数を制限しないでこれを行う方法を思いつきません。

ある種の順序付け列を追加して別の一意のキーを設定するだけでよいなど、明らかに欠けているものがあるように感じますが、かなりの量を読んでも何も思いつきませんでした。継承したデータ モデルに欠陥がある可能性もありますが、同様の柔軟性が得られるものは思いつきません。

テーブル ProductSupportArticles があります。

ProductID は Products.ID への外部キーであり、ParentArticleID は同じテーブル ProductSupportArticles.ProductSupportArticleID への外部キーです。チェック制約 ProductSupportArticleID != ParentArticleID があるため、記事がそれ自体の親になることはできません。

ただし、特定の製品に関連するサポート記事は、別​​の製品に関連する記事の親または子になることはできません。チェック制約または同様のことわざを追加するにはどうすればよいですか:(ProductID = (SELECT ProductID FROM ProductSupportArticles P WHERE ParentArticleID = P.ProductSupportArticleID))

または、テーブルを別の方法で実装するにはどうすればよいですか?