Zanetti Flashcards
Colecciones
Set -> no hay orden y no hay duplicados
List -> sí hay orden
Collection -> no orden, sí duplicados
Explicación de elección de singletable.
Se observa que no hay muchos atributos distintos entre ambas tablas. Basándonos en la simplicidad y en la posibilidad de definir queries polimórficas, la estrategia elegida es una singletable para el mapeo de la herencia. Esto nos será rentable tanto en performance como en tamaño (debido que nos ahorramos mucho espacio al realizar una sola tabla en vez de 3). A cambio tenemos que permitir nulos en los campos que no tienen en común y se agregará un campo que sirva para discriminar A de B.
Explicación de elección de Joined.
Se observa de que hay muchos atributos distintos entre las distintas tablas. La estrategia elegida es el JOINED. En comparación con la singletable, nos permite tener columnas sin muchos valores en null y ganamos la posibilidad de constraints. En contraposición, tenemos la necesidad de hacer consultas con muchos join, lo que trae una menor performance y una búsqueda manual “compleja”.
Explicación de elección de Table Per Class.
Se observa de que hay muchos atributo entre las tablas. Se usa un Table Per Class. En contraposición con el singletable nos permite tener columnas sin muchos valores nulls. Por otra parte, es la solución más compleja, requiere una mayor cantidad de entidades para definir y mantener, si en un futuro se requiere que el usuario tenga una lista de aportes, el aporte va a tener una fk a alumno y profesor, y si en un futuro aparece una Bedel, nuevamente habrá que agregar otra fk.
Anotations del diagrama de clases.
@MappedSuperclass abstract class PersistentEntity @Id @GeneratedValue long id
@Entity
@Table(‘Regiones’)
class Region extends PersistentEntity
@ManyToMany
Collection lugares
@ManyToOne
Casa casaPrincipal
@OneToMany
@JoinColumn(‘region_id’)
Collection vasallaDe
@Enumerated
Categoria categoria
@Entity
@Table(‘Lugares’)
@Inheritance(JOINED)
abstract class Lugar
@Entity
@Table(‘Castillos’)
class Castillo extends Lugar
// mapeo análogo en Ciudad
@Entity @Table(‘FuerzasMilitares’) @Inheritance(SINGLE_TABLE) @DiscriminatorColumn(‘tipo’) abstract class FuerzaMilitar
@Entity
@DiscriminatorValue(‘A’)
class Area extends FuerzaMilitar
// mapeo análogo en los otros tipos de fuerza
¿Qué cambios hubo en el modelo de objetos?
Se agregaron ids, se debió convertir la fuerza militar en clase abstracta debido a que una interfaz no se puede persistir.
¿Se utiliaron constriants?
Como vemos en la solución propuesta no se uso triggers, vistas ni procedimientos. Si se podrían aplicar not null sobre por ejemplo las siguientes columnas:
Lugarres.nombre
Castilos.cantidadDeTorres
Y constraints check sobre FuerzasMilitares tipo:
check FuerzasMilitares.tipo in (‘A’, ‘T’, ‘N’)
¿Las constraints para que sirven?
Te sirven para tener integridad.
Tipos de constraints
Not null/null, unique, default, check.
