問題タブ [database-integrity]

data consistencyとについて少し混乱していdata integrityます。Oracle データベースの概念から:

ウィキペディアより

data consistencyでは、との違いは何data integrityですか?

前もって感謝します。

、 、 の 3 つのテーブルaccountがaddressありaccount_addressます。account_addressテーブルにはとaccount_idがありaddress_idます。これは、標準的な多対多の関係です。

存在しないaccount_addressを指すレコードがあるという困惑した状況があります。を指しaccountている外部キーがあるので、これは起こりえないはずですよね？account_address.account_idaccount

では、この不可能であるべきことが起こっていることを証明しましょう。まず、テーブル定義を示します。

見る？FOREIGN KEY (account_id) REFERENCES account (id).

次に、その制約が失敗したことを示すいくつかのクエリを示します。

そのクエリにより、次の結果が得られます。

したがって、どうやらアドレス 15116 は 6 つの異なるアカウント (興味深いことに、アドレスと同じ ID を持つ 1 つのアカウント) に関連付けられています。しかし、これをチェックしてください：

結果がありません！ある時点で、外部キー制約が失敗したことを DBMS が教えてくれるはずではありませんか?!

私は2つの可能性しか考えていません:

1. 見ているものを誤解している
2. 私の DBMS は根本的な方法で誤動作しています

＃1が当てはまることを願っていますが、何を誤解している可能性があるのか​​ わかりません. それは私にとって最高のミステリーです。どんな考えでも大歓迎です。

Example table:

Assuming that id and tenant_id on each table make up composite primary keys, and that ticket_id is a foreign key to Ticket will this setup protect me from a circumstance where a TicketItem has tenant_id=1 and ticket_id=5 where the Ticket with id=5 has tenant_id=2? In simpler words, would the database allow me to link rows from 2 tables - each with different tenant_id - together, ruining my data, or does it protect me from this?

Also, does the above example seem like a "good" use of a composite primary key?

どうやらMySQLには、同じテーブルに対して定義されたトリガー内でテーブルを更新できないという本当に厄介な制限があります。
MySQL バージョン 5.1 を使用していますが、「この関数/トリガーを呼び出したステートメントで既に使用されているため、ストアド関数/トリガーのテーブルを更新できません」というエラーが表示されます。

私が持っているのはこれです：

階層的なフォルダー構造です。フォルダーには名前があり、場合によっては親フォルダーがあります (そうでない場合parentIdはゼロです)。
フォルダーが削除されたら、そのparentId中にあるすべてのサブフォルダーを変更して、存在しないフォルダーの子にならないようにする必要があります。

それはかなり単純です（ほとんど自明です）：

ただし、前述のように、独自のトリガー内でテーブルを更新できないため、このような単純なトリガーは MySQL では許可されていません。

何らかの方法でその効果をエミュレートすることにより、そのようなトリガーを実装する方法はありますか??

PS: 両方のステートメント (DELETE と UPDATE) を順番に送信することはお勧めしません。他に何もできない場合、それが明らかに最後の解決策です。

編集:
MyISAM エンジン (パフォーマンス上の理由) を使用しているため、外部キーを使用できません。

EMP スーパータイプを 2 つの FULL_TIME_EMP および PART_TIME_EMP サブタイプとともにモデル化することを目的とした次のデータベース リレーショナル スキーマがあります。

私が抱えている問題は整合性の問題です。つまり、フルタイムの従業員は FULL_TIME_EMP テーブルに対応する行しか持てず、同様にパートタイムの従業員は PART_TIME_EMP テーブルに対応する行しか持てないようにしたいと考えています。

以下のスクリーン キャプチャからわかるように、この整合性制約は適用されません。

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

そして、EMP テーブル:

PART_TIME_EMP テーブル:

最後に、整合性違反を示す FULL_TIME_EMP テーブル!!

データベース モデルの設計を変更して、この整合性制約を適用する方法はありますか? または、トリガーに頼る必要がありますか?

よろしく、

という名前のテーブルSuplProdに、列supplierとproductおよび 2 つのエントリと がある(Sony Ericcson, Xperia)とし(Apple, iPhone)ます。

Orders列supplier、productおよびという名前のテーブルを作成したいと思いますquantity。

(supplier, product)ただし、 table の組み合わせをOrdersからのエントリのみを含むように制限したいと思いますSuplProd。

たとえば、エントリはテーブルに対して(Sony Ericcson, Xperia, 1)有効ですが、そうではありません。Orders(Apple, Xperia, 1)

これはオラクルでどのように可能ですか?

ファイルとメモを顧客、ユーザー、プロジェクトなどにリンクするWebアプリがあります。最初は、customerNote、userNote、projectNote...などのテーブルがありました。

設計上の考慮事項：
1：N個の2乗テーブル（100を超えるcustomerNote、userNote、projectNote、... customerFile、projectFile ... etcテーブル）を管理
したくない2：動的SQL（TableName from LinkType）
3：リンクテーブルを使用するクリーンな方法がわかりません（100以上のNの2乗リンクテーブルなし）

これで、LinkIdとLinkTypeIdを持つNoteテーブルが1つあります。LinkIdはもちろん、client | User | Project|etcテーブルのPKです。LinkTypeIdは、リンクのタイプを指します。

したがって、この：
SELECT * FROM customerNote WHERE Id = 1210
SELECT * FROM userNote WHERE Id = 3281

現在は次のようになっています：
SELECT * FROM Note WHERE LinkId = 1210 AND LinkTypeId = 2（2は顧客）
SELECT * FROM Note WHERE LinkId = 3281 AND LinkTypeId = 3（3はユーザー）

私はこのアプローチの単純さを楽しんでおり、それらを私が至る所で呼び出す関数にラップしています。

私の質問は次のとおりです
。1：参照整合性がないと、どのようなパフォーマンスやその他の問題が発生しますか？
2：これはスケーラビリティの問題を引き起こしますか？
3：エレガントな解決策はありますか？

これは私の最初のSO投稿であり、皆さんの助けに前もって感謝します。

外部キーの依存関係を変更するときに、他の関連テーブルを更新するのに最適な場所を見つけようとしています。

正確には、「フラット」と呼ばれるテーブルと、「部屋」と呼ばれる別のテーブルがあります。

flat_id: {タイプ: INTEGER、foreignTable:flat、foreignReference: id、必須: true }

Room::SetFlatId() メソッドと同様に、Propel (1.3) は Room::SetFlat() を提供してくれました。

しかし、フラットに部屋を追加するとき、データベース定義よりも高いレベルで一貫性を保つために、関連する他のいくつかのテーブルを自動的に変更したいと考えています。Flat::addRoom(Room $room) をオーバーライドしてその親を呼び出してから、さらに変更を加えようと思いました。

しかし、'flat_id' 列が必要なため、Room オブジェクトが保存される前に SetFlatId() と setFlat() のいずれかが常に呼び出されるため、問題が発生しました。

ただし、Room オブジェクトが保存される前は ID がないため、他のテーブルの関連レコードを識別する room_id がないため、拡張 addRoom は機能しません。

これは、ルームが保存されたことに依存する Flat::addRoom() にコードを入れてはならないことを示唆しているようです。しかし、コードをどこに置くことができますか?

明らかに、Room オブジェクトを作成または変更した後に手動で呼び出すように要求することもできます。しかし、それが実際に行っていることは、一種のより高いレベルのデータベースの整合性を維持することなので、私はそれをしたくありません。「保存」メソッドの一方または両方に入れることができます。ただし、論理的には、部屋とフラットの間の関連付けが変更された場合にのみ実行する必要があります。

このコードはどこに行くべきですか?

私が以前に尋ねた質問に関してフォローアップしています。この質問では、間抜けな/不十分に記述されたmysqlクエリからpostgresqlへの変換を求めました。私はそれで成功したと思います。とにかく、私はmysqlデータベースからpostgresデータベースに手動で移動されたデータを使用しています。私は次のようなクエリを使用しています：

これがうまくいくと信じる理由があります。ただし、これは新しい問題につながりました。送信しようとすると、djangoから次のようなエラーが発生します。

私はここに投稿されたいくつかの回答を見てきましたが、私の問題の解決策を完全には見つけられませんでした（関連する質問はいくつかの興味深い読み物になりましたが）。これはログに表示されます。これは、insert-djangoを明示的に呼び出さないため、興味深いものです。

ただし、それを実行しようとすると、重複キーエラーが発生します。実際のエラーは、以下のコードでスローされます。

シーケンスなどを確認しましたが、順調に見えます。この時点で、どうすればよいかわかりません。これはdjango側の問題だと思いますが、よくわかりません。フィードバックをいただければ幸いです。

それが私のmodels.pyです：

ユーザーの追加は問題なく機能します。

リンクを追加しようとすると、整合性エラーが発生します。

私は何が欠けていますか？