エンティティが主キーを共有していない場合、特にデータベースが既に存在し、簡単に変更できない場合、JPA エンティティで継承を使用するベスト プラクティスは何だろうと思っています。
Oracle HRの例で使用されているような従業員データベースがあるとします。さて、そのデータベースはあまり現実的ではありません。通常、給与は時間とともに変化します。給与がどのように変化したかを追跡します。たとえば、労働契約では、毎年 12 月に従業員がマネージャーと会い、翌年の給与について話し合うことが規定されている場合があります。
したがって、HR.EMPLOYEES から給与フィールドを削除し、新しいテーブル HR.SALARIES を作成します。
EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)
主キーは EMPLOYEE_ID と VALID_FROM で構成されます。
したがって、Pat が 12 月にマネージャーの Michael に会い、新しい給与に同意した場合、新しいレコードを HR.SALARIES に挿入します。
ここで、人事部が新しいデータを入力する際にミスを犯したため、Pat が 1 月に誤った給与を受け取ったとします。彼女は問題を上司に報告し、上司は人事部に連絡し、HR.SALARIES の記録を修正します。彼女は 2 月の支払いで不足額を受け取ります。
年末には、会社の監査が行われます。監査人は、1 月に Pat に発行された給与小切手がデータベースの給与エントリと一致しない理由を知りません。監査人が、システムが特定の決定 (特定の金額の小切手を発行するなど) を行った理由を常に理解できるようにするために、変更履歴を保持する必要があります。
HR.SALARIES を次のように変更します。
EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)
CHANGE_DATE NOT NULL DATE
新しいテーブル HR.SALARIES_CHANGE_HISTORY を追加します。
EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)
CHANGE_DATE NOT NULL DATE
主キーは、EMPLOYEE_ID、VALID_FROM、および CHANGE_DATE で構成されます。
パフォーマンス上の理由から、変更履歴を別のテーブルに保持しています。HR システムによって読み取られることはほとんどありません。
いよいよ私の質問に行きます。CHANGE_DATE が HR.SALARIES_CHANGE_HISTORY.
JavaEE には @MappedSuperclass がありますが、最初は良さそうに思えますが、@MappedSupperclass を使用するクラス階層で異なる主キーを使用することはできません ( JSR-000338 JavaTM Persistence 2.1、セクション 2.4およびJSR 220: Enterprise JavaBeansTM,Versionを参照)。 3.0、セクション 2.1.4 )。
SALARIES と SALARIES_CHANGE_HISTORY のエンティティ Bean でコードの重複を避ける方法はありますか?