5

パフォーマンスが重要です: データベース内で削除/更新をカスケードするのと、Hibernate/JPA に任せた方が良いですか?

カスケードが DBMS 内にある場合、これはデータのクエリ機能に影響しますか?

それが重要な場合、私はHSQLDBを使用しています。

4

3 に答える 3

2

カスケード更新の場合、データベースに外部キー制約があると、アプリケーションスペースでそれを実行できません。

例：2文字の略語の主キーを持つ米国の州のルックアップテーブルがあるとします。次に、それを参照する郵送先住所のテーブルがあります。モンタナに誤って「MT」ではなく「MO」という略語を付けたため、ルックアップテーブルで変更する必要があるとのことです。

CREATE TABLE States (st CHAR(2) PRIMARY KEY, state VARCHAR(20) NOT NULL);
INSERT INTO States VALUES ('MO', 'Montana');

CREATE TABLE Addresses (addr VARCHAR(20), city VARCHAR(20), st CHAR(2), zip CHAR(6),
  FOREIGN KEY (st) REFERENCES States(st));
INSERT INTO Addresses VALUES ('1301 East Sixth Ave.', 'Helena', 'MO', '59620');

次に、データベース側のカスケード更新を使用せずに、間違いを修正します。以下は、MySQL 5.0を使用したテストです（実際には略語「MO」を使用するミズーリのレコードが存在しないと仮定します）。

UPDATE States SET st = 'MT' WHERE st = 'MO';

ERROR 1451 (23000): Cannot delete or update a parent row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

UPDATE Addresses SET st = 'MT' WHERE st = 'MO';

ERROR 1452 (23000): Cannot add or update a child row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

UPDATE Addresses JOIN States USING (st)
SET Addresses.st = 'MT', States.st = 'MT'
WHERE States.st = 'MO';

ERROR 1451 (23000): Cannot delete or update a parent row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

アプリケーション側のクエリでこの状況を解決することはできません。参照整合性制約が適用される前に、両方のテーブルでアトミックに更新を実行するには、データベースでカスケード更新が必要です。

于 2009-02-22T01:03:01.387 に答える
0

更新:同様の質問が既にここで回答されているように見えます SQL Server でカスケードを使用する場合/理由は?

あなたの質問に対するIMOの正解は、いつものように「場合によります」になります。機密情報 (金融、医療など) のストレージとしてデータベースを使用している場合、またはアプリケーション外の誰かがデータベースにアクセスできる場合は、Hibernate/JPA アプローチに投票します。データベースがログ (Web サイトのトラフィックなど) 用である場合、または組み込みデータベースを使用するソフトウェアを開発している場合は、カスケード操作を比較的安全に使用できます。

2. ほとんどの場合、Hibernate/JPA アプローチに投票します。これは、管理しやすく、予測しやすいためです。

私はあなたに話をします。少し前に、若い国が自国の通貨を変更することを決定しました (それは若い国で起こりました)。数年後、新しい DBA が通貨テーブルの行に廃止された通貨があるのを見て、それを削除することにしました (理由は誰にもわかりません)。何が起こったと思いますか？カスケード削除操作により、データベースの 30% が削除されました。カスケード操作を使用する IMO では、一方からステートメントを削除/更新するすべてに細心の注意を払う必要があり、他方からデータベース検証のための制約 (つまり、外部キー) の力を失います。

于 2009-02-17T07:58:34.283 に答える
0
  1. 正確さが鍵

この場合、データベースはデータの整合性に厳しい制約を設定 (および適用) するのに適した場所であるため、正確性とパフォーマンスはほぼ確実に密接に関連しています。

  • データベースへの複数回のラウンドトリップを回避
  • トランザクションを保持しなければならない可能性のある時間を短縮します
  • 外部キー インデックスに関連する内部構造を利用して、一部の実行計画を実行/再利用することなく実行できます。
于 2009-02-17T00:03:37.827 に答える