問題タブ [referential-integrity]

このレイアウトのテーブルがあります：

これに似た一意の制約を作成したい:

ただし、これにより、同じ を持つ複数の行が許可され(UserId, RecipeId)ますMenuId IS NULL。メニューが関連付けられていないお気に入りを保存できるようNULLにしたいのですが、ユーザー/レシピのペアごとにこれらの行を最大で 1 つだけ保存したいと考えています。MenuId

私がこれまでに持っているアイデアは次のとおりです。

1. null の代わりにハードコードされた UUID (すべてゼロなど) を使用します。
   ただし、MenuId各ユーザーのメニューには FK 制約があるため、ユーザーごとに特別な「null」メニューを作成する必要があり、面倒です。

2. 代わりにトリガーを使用して null エントリの存在を確認してください。
   これは面倒だと思うので、可能な限りトリガーを避けるのが好きです。さらに、データが決して悪い状態にならないことを保証してくれるとは信じていません。

3. それを忘れて、ミドルウェアまたは挿入関数にnullエントリが以前に存在していないかどうかを確認してください。この制約はありません。

Postgres 9.0 を使用しています。

私が見落としている方法はありますか？

私はPostgreSQLを初めて使用します。私は次のようなテーブルを持っています：

これらのテーブルによると、テーブルにデータを挿入したい場合Adress、Postgresはそのエラーを出します：

エラー：テーブル"address"の挿入または更新が外部キー制約"address_person_id_fkey"に違反しています詳細：キー（person_id）=（1）がテーブル"person"に存在しません。

私はPostgresでそれを学びました

インデックス（一意の制約を含む）と外部キーの制約は、単一のテーブルにのみ適用され、継承の子には適用されません。

私の質問は、トリガーを使用してこれをどのように修正できますか？サンプルコードは非常に便利です。

子テーブルにいくつかの行を挿入した後、「SELECT*FROMPerson;」でデータを確認できます。同じように。次のようになります。

人物テーブル

学生テーブル

従業員テーブル

私は 2 つの Access データベースを持っています。Main私のデータのほとんどをMemos格納し、データ型メモのデータを格納します。メモ フィールドについて読んだすべての記事で、メモ フィールドは破損しやすく、データベースを保護する唯一の安全な方法はメモを別のリンクされたデータベースに保存することだと述べているため、メモを別のデータベースに保存しています。

Memos次のフィールドを持つテーブルInfoがあります: ID(タイプ Autonumber 主キー) Info(タイプメモ)

Main次のフィールドを持つテーブルContentがあります: ID(タイプ Autonumber 主キー) infoID(タイプ Number) entryDate(タイプ Date/Time)

Contenttable からの有効な ID である値のみを受け入れることができるように、参照整合性を適用したいと考えていますInfo。しかしMemos、リンクされたデータベースであるため、できません。Infoからの値のみを に挿入できるように、データ入力プロセスの別の時点で制御を確立できますContentが、データベースの制約によって検証を強制する方法がある場合は、検証をコーディングしたくありません。

私が認識していないリンクされたテーブル間の整合性を強制する別の方法、または同じ DB にメモを保持できるようにメモ ストレージの問題を処理する別の方法はありますか?

私は、Oracle の一連のデータベース テーブルに取り組んでおり、わずかにポリモーフィックなデータで参照整合性を強制する方法を見つけようとしています。

具体的には、さまざまなテーブルがたくさんあります。たとえば、リンゴ、バナナ、オレンジ、みかん、ブドウ、その他 100 種類の果物があるとします。今、果物を含む手順の実行を説明する表を作成しようとしています。そこで、「Apple ID 100 を食べる」という行を挿入し、次に「バナナの皮をむく ID 250」という行を挿入し、次に「タンジェリン ID 500 を冷蔵する」という行を挿入します。

これまでは、次の 2 つの方法でこれを行ってきました。

1 - 考えられる果物の種類ごとに列を含めます。チェック制約を使用して、1 つの列を除くすべての列が NULL であることを確認してください。外部キーを使用して、フルーツへの参照整合性を確保します。したがって、私の架空の例では、列ACTION, APPLEID, BANANAID, ORANGEID, TANGERINEID、およびを持つテーブルがありますGRAPEID。最初のアクションには、 row があり'Eat', 100, NULL, NULL, NULL, NULL, NULLます。2 番目のアクションについては、'Peel', NULL, 250, NULL, NULL, NULL. などなど

このアプローチは、オラクルの RI の利点をすべて自動的に取得するには優れていますが、100 種類の果物に拡張することはできません。列が多すぎて実用的ではなくなります。どの種類の果物を扱っているかを把握するだけでも、難しい問題になります。

2 - 果物の名前を含む列と、果物 ID を含む列を含めます。これも機能しますが、Oracleにデータの有効性を何らかの方法で強制させる方法(AFAIK)はありません。したがって、列はACTION, FRUITTYPE、および になりFRUITIDます。行データは'Eat', 'Apple', 100、その後'Peel', 'Banana', 250などになります。しかし、誰かが Apple ID 100 を削除したり、'Eat', 'Apple', 90000000その ID を持つ Apple を持っていなくても、ステップを挿入したりすることを妨げるものは何もありません。

個々の果物の種類ごとに個別の列を維持することを避けながら、外部キーのほとんどの利点を維持する方法はありますか? (または、技術的には、何らかの巧妙なトリックで複雑さを隠すことができれば、100 列を使用することを確信できます。日常の使用で正気に見える必要があります。)

明確化:私たちの実際のロジックでは、「果物」は、共通性がほとんどないまったく異なるテーブルです。顧客、従業員、会議、部屋、建物、資産タグなどを考えてみてください。ステップのリストは自由形式であり、ユーザーがこれらのいずれかに対するアクションを指定できるようにする必要があります。これらの無関係なものをそれぞれ含むテーブルが 1 つあれば、問題はありませんが、非常に奇妙な設計になってしまいます。

私が尋ねる理由は、MySQL が現在サポートしていない特定の CHECK 制約を使用したいからです。この種の制約が適切に設定されていないと、アプリケーション コードがデータベースの責任をより多く引き受けるため、外部キーと参照整合性を使用する理由全体が減少するように見えます。

「ダム」データ モデルを作成し、すべての参照整合性チェックをアプリケーション コードのレイヤーに移動すると、参照整合性エラーがデータベースではなくアプリケーションでトラップされるため、テストがより簡単になる可能性があります。また、新しいモジュールの開発がスピードアップする可能性もあります。テストの前に、必ずしも参照的に完全である必要がないためです (用語ですか?)。

では、MySQL で「適切な」データ モデルに固執し、外部キーや「ON UPDATE CASCADE」ステートメントなどを保持することには、他に何か利点がありますか?

それとも、MySQL を捨てて別のものに移行するべきでしょうか?!

ありがとう！

だから私は比較的単純なシステムを持っています。モバイル クライアントは、(他のモバイル クライアントと共有されている) リモート SQL サーバーに同期したい sqlite データベースにレコードを作成します。そのため、電話の sqlite テーブルに新しいレコードを作成すると、RESTful API を介してその変更をリモート サービスにプッシュします。私が抱えている問題は、データに衝突がないように主キーをどのように並べるかです(つまり、電話のレコードは、サーバー上の完全に異なるレコードと同じ主キーを持っています)。クライアント上のレコードを参照し、サーバー上の同じレコードを参照するための通常の「ベスト プラクティスは何ですか?

削除ステートメントに問題があります。

私は2つのテーブルを持っています：

vehiculeテーブルからを削除するとき、テーブルvehicule_loan内の参照行をvehicule_uid保持する必要があります。

しかし、1つを削除しようとすると、次のエラーが発生します。

私はエラーを理解していると思います：vehiculeテーブルからaを削除した後vehicule_loan、vehiculeinvehicule_uidは何も指しません。

しかし、行を保持する方法はありvehicule_uidますか？

上記を考えると、どちらのテーブルのレコードも削除できません - きちんとした解決策はありますか? 私がやりたいことは、デザインをソートして、リンク テーブルを純粋なリンク テーブルにし、それ自体が値を保持しないようにすることです。行を実際に削除する必要はなく (行にフラグが付けられていても、実際には削除されていません)、もちろん、DefaultValue が NULL になる可能性があるため挿入できます。

編集:私のダウンマーカーに応えて、私は言及すべきでした.ON DELETE CASCADEとTRIGGERの両方を検討しました.これらのシナリオの代替案を探しています.ON DELETE SET NULLは明らかに機能しません.

他の多くのシステムからのデータを格納するための中央リポジトリであるシステムを構築しています。他のシステムのデータが更新されたときに中央リポジトリを更新するには、同期プロセスが必要です。中央リポジトリが同期する必要があるシステムと必要な同期のタイプを識別するための sync_action テーブルがあります。変更される可能性が非常に低い一連の定義済みアクションがあります。スリム化されたシステムを以下に示します。

私が見ているように、これには2つの方法でアプローチできます。

オプション 1 ) Action3 つのアクションが利用可能なテーブルを用意します。sync_action外部キーを使用して必要なアクションを参照するテーブルを用意します。

表:システム

表:アクション

表:同期アクション

オプション 2 ) 外部キーの代わりに、sync_action.action列にチェック制約を使用して、アクションのみInsert/Update/Deleteを挿入できるようにします。

表:同期アクション

整合性制約、外部キーとチェック制約の間で決定するときに、どちらがより良いアプローチであるかを決定する要因を知りたいです。同様のスレッドがありましたが、十分に決定的なものではありませんでした。これは解釈次第かもしれませんが、どんな考えでも大歓迎です。

乾杯