Hibernate: ¿por qué usar many-to-one para representar uno a uno?

Question

He visto a personas usar asignaciones de muchos a uno para representar relaciones uno a uno. También lo leí en un libro de Gavin King y en artículos.

Por ejemplo, si un cliente puede tener exactamente una dirección de envío y una dirección de envío puede pertenecer a un solo cliente, la asignación se da como:

<class name="Customer" table="CUSTOMERS"> 
    ... 
    <many-to-one name="shippingAddress" 
       class="Address" 
       column="SHIPPING_ADDRESS_ID" 
       cascade="save-update" 
       unique="true"/> 
    ... 
</class> 

Las razones de libros como (citándolo):

"no te importa lo que está en el lado de destino de la asociación, por lo que se puede tratar como una asociacióna-uno sin el muchos parte."

Mi pregunta es, ¿por qué usar many-to-one y no one-to-one? ¿Qué tiene que ver con one-to-one que lo hace una opción menos deseable para many-to-one?

Gracias.

Answer 1

Existen varias formas de implementar una asociación uno a uno en una base de datos: puede compartir una clave principal pero también puede usar una clave externa con una restricción única (una tabla tiene una columna clave externa que hace referencia la clave principal de la tabla asociada).

En el último caso, la forma de hibernación para mapear esto es usar una asociación many-to-one (que permite especificar la clave externa).

La razón es simple: No te importa lo que está en el lado de destino de la asociación , por lo que puede tratarlo como un a uno sin la asociación parte muchos. Todo lo que desea es expresar "Esta entidad tiene una propiedad que es una referencia a una instancia de otra entidad " y utilizar un campo de clave externa para representar esa relación.

En otras palabras, el uso de un many-to-one es la forma de asignar uno-a-uno asociaciones de claves externas (que en realidad son tal vez más frecuente que compartidos primarias clave asociaciones uno-a-uno).

Answer 2

Incluso está en los documentos oficiales de Hibernate: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/associations.html#assoc-bidirectional-121.

No es del todo descabellado. El extremo many-to-one dice: Me asignaron a través de una de mis columnas a una ID del -un extremo. Utilizaría exactamente el mismo esquema de base de datos para muchos a uno.

Answer 3

Yo diría que el problema está fundamentalmente relacionado con la desigualdad de impedancia relacional del objeto. Para poder relacionar las dos representaciones de objeto en una base de datos, necesita tener algún tipo de relación entre sus tablas. Sin embargo, la base de datos solo conoce la relación 1: N: todos los demás se derivan de ella.

Con las bases de datos relacionales y los lenguajes de objetos, le corresponde al desarrollador encontrar la representación menos artificial del concepto que quiere representar (en este caso, una relación 1: 1).

Answer 4

Según tengo entendido, hibernate requiere que la clave principal de ambos objetos coincida en una relación de 1 a 1. Muchos a 1 evita ese requisito.

Sin embargo, muchos a 1 pierden la información de que solo debe haber uno o quizás ningún objeto por muchos lados.

Answer 5

La mayor diferencia es que con una clave compartida asignación uno a uno los 2 objetos están vinculados entre sí, existen juntos.

f.e. si crea un persona y una clase Dirección que están unidos a las tablas con el mismo nombre, cada persona tendrá exactamente una dirección ...

clase Persona, propiedades: Dirección persona tabla, las columnas: id, nombrar dirección de la tabla, las columnas: id, ciudad

con muchos-a-uno relación de la estructura de la tabla cambia un poco, pero el mismo efecto se puede lograr ...

• persona de clase -> Propiedades:
• persona mesa -> Columnas: ID, NOMBRE, AddressID (FK)
• tabla de direcciones -> Columnas: ID, ciudad

... pero incluso Más. Ahora bien, esta persona puede tener varias direcciones: Persona

• clase -> Propiedades: Persona
• mesa -> Columnas: ID, nombre, AddressID (FK), shippingaddressid (FK)
• tabla de direcciones - > columnas: ID, ciudad

Las dos claves externas (AddressID y shippingaddressid) podría apuntar a una sola entrada DB ... o una sola dirección podrían pertenecer a 2-3 personas. Entonces, ¿cuál es el concepto de muchos a uno del lado de la persona? es uno a muchos desde el lado de la dirección.

y solo adivina qué aspecto tiene una asociación uno a muchos con solo 1 elemento. Sí, solo como uno a uno ...

NOTA: la dirección en realidad debería ser un objeto de valor , no debe compartirse en DB (por lo que es un ejemplo tonto, pero supongo que estará bien)

Así que en resumen:

1. en O asignación uno a uno es más difícil de manejar
2. uno a uno tiene sus limitaciones
3. usando muchos a uno en su lugar es mo Es flexible y lo mismo se puede lograr con