問題タブ [referential-integrity]

列が対応する自明なディメンション テーブルなどへ(fk_dim1value, fk_dim2value, ..., value)の外部キーであるようなファクト テーブルを含むディメンション モデルを考えてみましょう。fk_Xdim1value (id, value), dim2value (id, value),

これらの事実と次元のテーブルは、さまざまなソースから自動的に収集されるため、多くのテーブルが存在します...そしてそれらは冗長です: すべての次元値テーブルは構造的に同一であり(id, value)、それ以上のセマンティクスを持たないテキスト値の単純なコレクションを表します (唯一の違いは、さまざまなファクト テーブルでそれらを参照するさまざまな外部キーです)。あまり重要でないディメンション タイプは後で登場する可能性がありますが、さまざまなタイプのディメンションのセットは小さいままです。

dimvalue (fk_dim, dimvalue_id, value)したがって、ディメンション テーブルを、 tableをfk_dim参照する1 つのテーブルにマージし、各ディメンション内dimension (dim_id, name)でdimvalue_idのみ一意になるようにしたいと考えています。自然な主キーは複合です: (fk_dim, dimvalue_id).

ファクト テーブルの外部キー列はすべて同じテーブルを参照するようになりましdimvalue (fk_dim, dimvalue_id, value)たが、もちろん、各列は特定のディメンションに関連付けられているため、そのディメンションの値を具体的に参照することに限定する必要があります (統合テーブルの水平パーティション)。dimvalue）。

これを行う（賢明な）方法はありますか？

「半複合」外部キーのようなものを意味します。つまり、複合 PK の「スライス」への単一列参照であり、他の列には固定値があります。「完全複合」FK になりますFOREIGN KEY (col1, col2) REFERENCES dimvalue (fk_dim, dimvalue_id)が、ここでは固定されているため、キーの「ホーム」側は 1 つの列にすぎず、主キーfk_dimの 2 番目の列を参照します。dimvalueのようなものFOREIGN KEY (fk_dim7value) REFERENCES dimvalue (fk_dim=7, dimvalue_id)。

そのようなことは可能ですか？それとも、この最後の段落で道に迷っていますか? テーブル全体への外部キーだけをあきらめて、dimvalueチェック制約を追加してディメンションで制限する必要がありますか? それとも、参照整合性のために、さらにあきらめて、別々の同一のテーブルをすべて受け入れる必要がありますか?

(書き込みパフォーマンスに対する制約の影響は重要ではありません。読み取りパフォーマンスは設計目標です。)

オブジェクトのデータを 1 つのデータベースに追加するために TransactionScope を使用しています。

擬似コード:

InsertChildIntoTableB() で例外が発生し、TableB の ParentID に TableA に一致する主キー エントリがないというエラーが表示されます。

接続は再利用されます。

どうすればこれを回避できますか? TableA で SELECT WITH (NOLOCK) を実行すると、新しく挿入された親レコードが表示されますが、次の子レコードの挿入では表示されません。

明確にするために編集：foreachループでは、すでに挿入されていますが、コミットされていない新しいParentIDがあります。問題は、親 TableA の TableB の FK がコミットされていない新しい TableA PK ID を認識できないため、子の TableB への挿入が失敗することです。

単純なアプリを作成しているとします。モデルは、「プロジェクト」には「カテゴリ」があるということです。プロジェクトのカテゴリは、可能なすべてのカテゴリを含むドロップダウン リストから選択して編集できます。

ユーザーは次のカテゴリを作成します: C1、C2、C3。

ユーザーは、次のプロジェクト、カテゴリの関連付けを作成します: [P1, C1]、[P2, C2]、[P3, C3]

その後、カテゴリ C2 は削除されました。ここで、ユーザーがプロジェクト P2 のカテゴリを編集しようとすると、いくつかの問題が発生します。ドロップダウン リストに入力するには、カテゴリを取得する必要があります。ただし、削除されたカテゴリは取得されません。したがって、C2 は取得されません。(削除されたカテゴリが取得された場合、ドロップダウン リストは削除された使用できないフィールドでいっぱいになります)

b. C2 も取得すると、ユーザーが削除されたカテゴリ C2 を P2 に再度割り当てることができるリスクがあります。

これを処理するための最良の設計アプローチは何ですか?

私の質問は、MySQL データベースの参照整合性の概念に関するものです。DBA からの何らかの制限により、MySQL の参照整合性機能を使用することは許可されていません。私の質問は、「MySQL に参照整合性機能がない場合、MySQL に外部キーの概念をどのように実装できますか?」ということです。

ありがとう。

「質問のグループ」のテーブルがあるとしましょう

そして、質問のグループごとに、「質問」と「可能な回答」があります。

ここで、PHP / HTMLで、グループ42の質問と可能な回答の（仮想）完全外積を実行して、ユーザーが回答を選択する2エントリのテーブルを作成します（HTMLバージョン） 。

私は
insert into answers (question, answer, ...) values (5, 135, ...)歯
と
insert into answers (question, answer, ...) values (89, 8, ...)映画のために必要になることを知っています

問題は、テーブル内の質問と回答の両方をanswers同じグループの質問に「属する」ように強制する方法はありますか？

insert into answers (question, answer, ...) values (709, 71, ...)
質問709はグループ9071に「属し」、回答71はグループ42に属しているため、これは許可されません。

現在、参照整合性はほとんどなく、自己結合する多数のテーブルがあります (実際には、結合された個別のテーブルまたはビューとして表す方がよいでしょう)。

これらのテーブルが相互にどのように関連しているかは、スキーマで明示的にではなく、ストアド プロシージャのロジックで暗黙的に認識されます。これを変更することを検討しています。

最初のステップは、暗黙の関係を実際に理解し、それらを文書化することです。

だから私の質問は...

すべてのストアド プロシージャに注目する以外に、その暗黙の情報を抽出する最善の方法は何ですか。独自の SQL を記述してシステム テーブルに問い合わせたり、SQL-DMO モデルを利用したり、実際にはコンピュータがより多くの作業を行い、私がより少ない作業を行えるようにするあらゆるツールを検討します。

以前は、独自の認証メカニズムを実装したときに、アプリケーションの MySQL データベース内の他のテーブルとの関係を持つユーザー テーブルを作成していました。ただし、ActiveDirectoryMembershipProvider の使用を検討しているため、AD ユーザーとそれらのテーブルの間に同様の関係を作成する方法がわかりません。

この問題を解決する通常の方法は何ですか? 既存のユーザーに対応しないユーザー ID を持つレコードを誰かが挿入する可能性があるという事実を受け入れる必要がありますか? 私は現実的にはそうなるとは思っていませんが、データベース レベルで整合性を確保することに慣れています。

DotnetとSQLServerをバックエンドとして使用するアプリケーションのアーカイブモジュールを開発しています。アーカイブの複数のアプローチから、選択したしきい値までの完全なデータベースを別のミラーリングされたデータベースにアーカイブするカスタムアプリケーションを構築し、アーカイブされたアイテムをソースDBから削除することにしました。これは、リンクサーバー、ジョブ、SSIS、レプリケーションなどからではなく、カスタムアプリケーションから実行する必要があります。

アーカイブの実行ごとに空になり、再度書き換えられるアイテムがいくつかあります。モジュールの構築を開始する前に、ミラーリングされたアーカイブデータベースから外部キー制約を削除して、これらのテーブルを空にして再書き込みしたときに参照整合性違反を回避することを検討していました（制約のみが削除され、列と値はアーカイブに引き続き存在します） DB）。しかし、このアプローチは私には怪しげなようには見えませんが、ちょっと気がかりです。だからここで私はこれに対処するための正しいアプローチは何でしょうか？

私はCouchDBを初めて使用し、それについて学びます。参照整合性に対するCouchDBのサポートに出くわしませんでした。CouchDBドキュメントのフィールドに外部キーを作成できますか？

たとえば、注文書で使用されているベンダー名がベンダーデータベースで利用可能であることを確認することは可能ですか？

CouchDBは参照整合性をサポートしていますか？また、ドキュメント内のフィールドを主キーとして作成することは可能ですか？

php/mysqlアプリケーションに2つのデータベースがあります。1つはユーザーデータ用で、もう1つはコンテンツ用です。

最近、参照整合性を強制するために、innodbテーブルを使用する必要がありました。明らかに、これらの関係に参加するにはユーザーテーブルが必要になります。

参照整合性を維持しながら、データを分離しておく方法はありますか？

アドバイスをいただければ幸いです。

ありがとう。