Elección de una estrategia de conservación de la jerarquía

Descripción

Cada una de las estrategias y técnicas anteriores tiene sus propias ventajas y desventajas. Las recomendaciones generales para elegir una estrategia específica se verán así:

Estrategia TABLE_PER_CLASS basada en UNION

Esta estrategia se elige mejor si no se requieren asociaciones y consultas polimórficas. Si rara vez lo hace (o no lo hace en absoluto), "seleccione el usuario del Usuario usuario". Si no tiene ninguna clase de Entidad que se refiera a Usuario, esta es la mejor opción (ya que aún puede agregar asociaciones y consultas polimórficas optimizadas).

estrategia SINGLE_TABLE

Esta estrategia debe ser utilizada:

a) Sólo para tareas sencillas. En situaciones donde la normalización y la restricción NOT NULL son críticas, se debe preferir la estrategia #3 (JOINED). Tiene sentido pensar si en este caso no vale la pena abandonar por completo la herencia y sustituirla por la delegación.

b) Si se requieren consultas y asociaciones polimórficas, así como definición dinámica de una clase concreta en tiempo de ejecución. Al mismo tiempo, las subclases declaran relativamente pocos campos nuevos y la principal diferencia con una superclase está en el comportamiento.

Y además de eso, tienes una conversación seria con el DBA.

estrategia UNIDA

Esta estrategia es la más eficiente en términos de velocidad y RESTRICCIONES. Es adecuado en los casos en que se requieren asociaciones y consultas polimórficas, pero las subclases declaran relativamente muchos campos nuevos.

Una palabra de precaución aquí: la decisión entre JOINED y TABLE_PER_CLASS requiere la evaluación de planes de ejecución de consultas en datos reales, ya que el ancho y la profundidad de la jerarquía de herencia pueden hacer que el costo de las uniones (y, como resultado, el rendimiento) sea inaceptable.

Por separado, vale la pena tener en cuenta que las anotaciones de herencia no se pueden aplicar a las interfaces.

EXPLÍCITO

También puede haber una situación en la que tenga una jerarquía de clases de entidad con una estrategia de almacenamiento compartido en la base de datos. Pero por alguna razón, no desea que se devuelva alguna clase de jerarquía cuando se realiza una consulta en la clase base.

Hay una anotación para esto:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Si lo añadimos a la clase Cliente :

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
class User {
  int id;
  String name;
  LocalDate birthday;
}

@Entity
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}

@Entity
@Polymorphism(type = PolymorphismType.EXPLICIT)
class Client extends User {
   String address;
}

Luego, las consultas HQL ignorarán los objetos de esta clase cuando consulten la clase base:

List<User> accounts = session.createQuery("from User").getResultList();

Esta consulta devolverá una lista de objetos Usuario y Empleado , pero no Cliente .