HibernateオブジェクトID

Question

Java永続性がHibernateの場合、gavinは等価比較のためにビジネスキーを使用することを提案しています。ビジネスキーには複数のフィールド比較が含まれるだけでなく、将来完全なビジネスキーのセマンティクスが変更されないという保証はありません。私たちは非理想的な世界に住んでおり、ビジネス要件や法律は頻繁に変わります。このような場合、複数のビジネス・キー・セマンティクスが格納されたデータベースにデータが残されます。問題を2つの部分に分割したい：

1. 永続オブジェクトまたは分離オブジェクトを厳密に処理するとき。

2. 一時オブジェクトを扱うとき。

3. 永続オブジェクトとデタッチされたオブジェクトを扱う場合、同等性とハッシュコードのためにサロゲートキーを使用することにはまだ下げ気味はありません。 2つの永続オブジェクトまたは分離されたオブジェクトは、同じ主キーを持つ場合は等価です。仮定するのは間違っていますか？

4. 一時的なオブジェクトを処理する場合、ビジネスキーのセマンティクスを使用してオブジェクトを比較し、残りの属性で同じビジネスキーで異なる値を持つ2つの一時オブジェクトを保持しようとすると、

大量のトランザクションが読み取り/更新される読み取り負荷の高いアプリケーションでは、この戦略のほうがパフォーマンスが向上するはずです。

Answer 1

オブジェクトアイデンティティーとHibernateの問題は、一時オブジェクトを使用することです。主キーはいつ作成されますか？答えがDBに書き込まれたとき（OracleのようなDB制御の主キー生成を使用）、潜在的な問題があります。

プライマリキーが等価性チェックの基礎として使用され、ハッシュコード生成の一部である場合、プライマリキーが生成される前後でオブジェクトが同じではないため、ハッシュコードコントラクトが破られます。

可能であれば、オブジェクトの作成時に設定できる生成された主キー（UUIDなど）を使用してください。これにより、ハッシュコードと等価性チェックが一貫性を保ちます。

Answer 2

私はすべてのクラスのための完全なビジネスキーを見つけて苦労していましたが、変わらないユニークなものがない状況でUUIDを使用することになりました。しかし、今、私はデータベースのサロゲートキーを使用し、一時オブジェクトの平等に依存しなければならない状況を避けます。それは簡単で、間違いを起こしにくく、速くなりました。アプリケーションの種類によって異なる場合がありますが、典型的なCRUDアプリケーションの場合、オブジェクトは通常、コレクション内で処理する前にデータベースに格納されます。