c# - que - tipos de relaciones en base de datos ejemplos
es una mala estrategia de relación uno a uno (2)
No, esta bien. No se trata solo de relaciones sino de orientación a objetos. Fundamentalmente, una billetera no es una parte indesligable de una persona.
Mirando más allá de eso, mientras que la billetera podría pertenecer a un ''John'' específico ahora, ''James'' podría darse como regalo. Desde la perspectiva de los datos, es mucho mejor cambiar los campos de WalletId de John y James, de los cuales uno puede ser nulo (aunque no en su caso) si no tienen una billetera.
El usuario siempre tiene una billetera. Una Cartera pertenece siempre a un Usuario.
Como quiero separar las propiedades relacionadas con Money Wallet, creé un objeto Wallet y para poder rastrear las transacciones monetarias, ... creé
public Wallet : Entity<int>
{
public double Amont {get; set;}
public IList<MoneyTrans> Transactions {get; set;}
}
Dado que obviamente se trata de una relación de uno a uno, ¿está bien mapear usando una relación de uno a uno?
¿Es uno a uno mala estrategia?
Tuve que anexar la respuesta, con el punto de vista opuesto. No use mapeo de one-to-one . Al menos con NHibernate.
No estoy hablando del diseño impulsado por el dominio conceptual. Solo sobre mi experiencia con el diseño de DB y el uso de NHibernate.
1) one-to-one : diseño de base rígida
En primer lugar, el diseño con claves primarias compartidas (excepto la herencia) podría generar muchos problemas más adelante, cuando se modifiquen los requisitos del Negocio.
El escenario típico, muy similar al ejemplo 23.2. Autor / Trabajo , donde el autor se asigna one-to-one a la persona . Por lo tanto, la identificación (clave principal) del Autor proviene de una Persona (id). Tarde o temprano, los negocios vendrán y preguntarán si podríamos tener una persona asignada al autor (ver ejemplo de Lars Kepler )
Lo que trato de decir aquí es: Capítulo 24. Mejores prácticas (permítanme citar un punto)
Declarar propiedades de identificador en clases persistentes.
NHibernate hace que las propiedades del identificador sean opcionales. Hay todo tipo de razones por las cuales debes usarlas. Recomendamos que los identificadores sean "sintéticos" (generados, sin significado comercial) y de tipo no primitivo. Para una flexibilidad máxima, use Int64 o String.
Como mencioné aquí (y según mi experiencia) , es muy beneficioso tener todas las entidades con sus propias claves primarias sustitutas . Los cambios en las relaciones que vendrán después afectarán solo las referencias (además de las claves sustituidas), no las tablas / entidades mismas.
2) one-to-one con NHibernate no puede ser perezoso
De hecho, esta es la razón por la cual (a pesar de que lo intenté pocas veces) actualmente no utilizo el one-to-one en absoluto. El one-to-one no es compatible con la carga diferida. Busque más información pero puede encontrar una buena explicación aquí:
- Ayende NHibernate uno a uno (una cita)
En otras palabras, uno a uno no se puede cargar de forma perezosa, que es una de las razones por las que se recomienda utilizar dos de muchos a uno en su lugar.
- Algunas explicaciones sobre la carga diferida (uno a uno)
Como se menciona en uno de los enlaces en los comentarios debajo de la pregunta (cite)
Puede incluir todos esos atributos como columnas en su tabla de entidades, pero en ese caso, muchas columnas terminarían vacías para un número significativo de las entradas.
O bien: puede poner esos atributos "opcionales" en una tabla separada, configurar una relación 1: 1 (o más bien: 0: 1) con la tabla de entidad base,
Bueno, con NHiberante no obtendrás tanta mejoría. Esta sugerencia es incorrecta. La carga lenta de uno a uno no es compatible ...
RESUMEN:
Es por eso que recomendaría encarecidamente: usar many-to-one o one-to-many donde sea posible. Ganarás más ...