問題タブ [referential-integrity]

これが私のデータベースの単純化です：

次に、QuoteテーブルとJobテーブルに個別に関連する他のテーブルがあります。

ここで、ジョブと見積もりに関して顧客が残した電話メッセージをユーザーが記録できるメッセージテーブルを追加する必要があります。

2 つの同一のテーブル ( QuoteMessageとJobMessage ) を作成することもできますが、これは DRY プリンシパルに違反しており、面倒です。

Messageテーブルを 1 つ作成できます。

しかし、これにより、制約を使用して参照整合性を強制することができなくなります。また、後で Linq to SQL を使用して開発側で問題が発生することも予測できます。

この問題に対するエレガントな解決策はありますか、それとも最終的に何かを一緒にハックする必要がありますか?

火傷

Joel Spolskyがポッドキャスト 014で、外部キーをほとんど使用したことがないと述べたのを聞いたのを覚えています (私の記憶が正しければ)。ただし、データベース全体での重複とその後のデータ整合性の問題を回避するために、それらは非常に重要に思えます。

人々はその理由について確固たる理由を持っていますか (Stack Overflow の原則に沿った議論を避けるため)?

編集： 「外部キーを作成する理由がまだないので、これが実際に外部キーを設定する最初の理由かもしれません。」

私は非常に大きなデータベース（PostgreSQLで実行）を持っており、それらの間に高度な関係（外部キー、削除カスケードなど）を持つ多くのテーブルが含まれています。いくつかのテーブルからいくつかのデータを削除する必要がありますが、カスケード削除のためにデータベースから実際に削除されるデータの量がわかりません。

削除してはいけないデータを削除しないことを確認するにはどうすればよいですか？

私はテストデータベースを持っています-私がやりたいことができる本物のデータベースのコピーです:)

私が持っている唯一のアイデアは、前後にデータベースをダンプしてチェックすることです。しかし、それは快適に見えません。別のアイデア-データベースの一部をダンプします。これは、私が思うに、DELETEステートメントの影響を受けないようにし、データの削除の前後にこの部分を確認する必要があります。しかし、それを行う簡単な方法はわかりません（数百のテーブルがあり、そのうちの10までで削除が機能するはずです）。それを行う方法はありますか？

問題を解決する方法の他のアイデアはありますか？

これに関するGoogleの結果は少し薄いですが、それは簡単には不可能であることを示唆しています.

私の具体的な問題は、テーブル B に「table_a_id」列が含まれるように、互いに関連する 2 つのテーブルの ID の番号を付け直す必要があることです。B の子が古い ID を指しているため、最初にテーブル A の番号を付け直すことはできません。最初にテーブル B の番号を付け直すことはできません。作成される前に新しい ID を指すことになるからです。3 つまたは 4 つのテーブルについて繰り返します。

「トランザクションを開始する、ref の整合性を無効にする、ID を整理する、ref の整合性を再度有効にする、トランザクションをコミットする」ことができる場合に、個々の関係をいじる必要はありません。Mysql と MSSQL の両方がこの機能 IIRC を提供しているので、Postgres が提供していなかったら驚くでしょう。

ありがとう！

与えられたスキーマ:

およびビジネス ルール:

ソート計画は、同じ machine_type の任意のマシンに割り当てることができます。

SCHEDULE で、 machineとsort_planによって参照されるタプルが同じmachine_typeを持つように強制するにはどうすればよいですか?

スキーマは、必要に応じて変更できます。

与えられたスキーマ

ここで、PERSON.spouse は PERSON.name の外部キーです。未婚の場合や情報がない場合は NULL が必要になります。

ヌルに反対する議論を続けますが、この場合、どのようにヌルを回避しますか?

代替スキーマがあります

ここで、SPOUSE.name* は PERSON への FK です。ここで私が目にする問題は、配偶者が 1 人だけであることを保証する方法がないことです (考えられるすべての UNIQUE 制約があっても、配偶者が 2 人いる可能性があります)。

部品表スタイルの関係でヌルを除外する最良の方法は何ですか?

画像サイトをまとめています。基本的なスキーマは非常に単純な MySQL ですが、画像に関連付けられている可能性のある管理者フラグ (「不適切」、「著作権」など) を表現しようとすると、問題が発生します。私の現在の考えは次のとおりです。

(読みやすくするために省略しています。さまざまな外部キーとインデックスが順番に並んでいます、誓います)

tblImageFlags.flagTypeIDは、フラグ型のルックアップ テーブルで外部キー化されており、ご想像のとおり、 で外部キー化するtblImageFlags.resolutionTypeID 必要luResolutionTypes.resolutionTypeIDがあります。当面の問題は、フラグが最初に発行されたときに、論理的な解決タイプがないことです (これは の適切な使用法であると宣言しますNULL)。ただし、値が設定されている場合は、ルックアップ テーブルに対して外部キーにする必要があります。

この状況に対する MySQL 構文の回避策が見つかりません。それは存在しますか？最高の準優勝者は次のとおりです。

• 「モデレートされていない」解像度タイプを追加する
• NULLエントリを追加しますluResolutionTypes.resolutionTypeID(これは列でも機能しAUTO_INCREMENTますか?)

洞察をありがとう！

PSボーナスは、データベースの場合、それが「インデックス」か「インデックス」かを教えてくれた人に指摘します。

フォローアップ: テーブル構造の構文エラーであることが判明したことを指摘してくれた Bill Karwin に感謝します (NOT NULL許可したい場合は、列を に設定しないでくださいNULL!)。そして、それらのボーナスポイントを与えるのに十分なカルマが得られたら、私はします:)

それぞれが他方の主キーへの参照を必要とする 2 つのテーブルにレコードを入力する最良の方法は何ですか?

私の考えは、それらの間に「リンク」テーブルがあり、両方がデータベースに書き込まれるか、次の複雑な一連のコマンドによって取り込まれます

mySQL データベースに接続して整合性を維持しながら、PHP でこれを行うにはどうすればよいでしょうか?

トランザクションを使用する必要がありますか?

データベース テーブルの大部分が他の 1 つのテーブルと強い関係を持つアプリケーションがあります。現在、外部キーを使用して参照整合性を強制していますが、これが本当に最善のアプローチであるかどうか疑問に思っています。プライマリ テーブルのデータは、ビジネス ユーザーが管理インターフェイスから削除できます。つまり、カスケード削除を実行する (または複数の削除ステートメントを記述する) 必要がありますが、他のすべてのデータを本当に削除する必要があるかどうかはわかりません。同時に。それは、後日役に立つ*かもしれない*多くのデータである可能性があります (おそらく報告しますか?)。ただし、二次テーブルのデータは、基本的に、一次テーブルとの関係が存在しない限り、アプリケーション自体には役に立ちません。

1970 年に Edgar Codd によって最初に定義されたリレーショナル モデルのルールを理解しようとしています。

具体的には、参照整合性が彼のリレーショナル モデルの一部であるかどうかに興味があります。次の例でデモンストレーションを試みます（この質問をきれいにするためだけに）：

お客様

請求書

さて、ご覧のとおり、顧客 (外部キー) がMaryである請求書が 1 つあります。これは彼のリレーショナル モデルに違反しますか? エドガー・コッドはこれを見て、「なんてこった」と言うでしょうか? それとも、彼は言うでしょうか、それはまったく問題ありません...

これは理論的な問題です。