tengo que guardar esta información en una base de datoscómo guardar relación marital en una base de datos
persona -> está casada con -> Persona
¿Dónde debo guardar esa información? ¿Cuál es el patrón de diseño adecuado si solicito aquí?
¡Gracias!
Si sólo puede ser marieD a una persona: 1: 1
-------------
- Person -
-------------
id (key)
maried_to_id (foreign key)
si puede ser marieD a más de una persona o desea realizar un seguimiento de mariages anteriores, n: n
-------------
- Person -
-------------
person_id (key)
-------------
- Mariage -
-------------
first_person_id (foreign key)
second_person_id (foreign key)
start_date
end_date
(también first_person_id + + second_person_id fecha forma una clave única para mariage. Se puede dejar de lado la fecha, pero entonces no sería rastreado remariages)
El campo maried_to_id debe completarse en ambas personas? Es información repetida, pero no puedo dejarla en blanco en uno de ellos porque no sería verdad –
@mauro: sí, debe llenarse para ambos. por supuesto, necesitarás algo de lógica para asegurarte de que esta condición se verifique (es decir, no elimines a alguien si la persona está casada, no estás casada con personas inexistentes ...) – marcgg
¡Has olvidado EndDate! -) Y, siendo un poco conservador, lo haría más preciso para el nombre: HusbandId, SpouseId. De esta manera usted aplica la entrada de 1 vía. Pero no funcionaría con el matrimonio homosexual. –
recomendaría siguiente estructura Digamos que el nombre de la tabla es Persona.
.....
No hay necesidad de crear nave de la relación de clave externa.
Las claves foráneas deberían ** forzarse ** casi por completo mediante una relación FK – Jamiec
Tenga en cuenta que el estado está duplicado, ya que a.MarriedTo (b) también debería significar b.MarriedTo (a). – Piskvor
sí, la complicación de tener que ser casado en múltiples filas es un problema de normalización ... – Randy
Puede hacerlo con una columna "Cónyuge" en la tabla "Persona" que puede ser nula (para el caso de una persona soltera).
Si está casado, este posee la identificación de la otra persona, ya que es una clave externa.
Una mejor solución sería una tabla separada "matrimonio" que tiene al menos tres columnas:
MarriageId
Person1Id
Person2Id
...
La persona de identificación son claves externas en la tabla "Persona", y usted debe hacer la combinación de MarriageId , Person1Id y Person2Id son únicos para evitar agregar una fila donde las personas se cambian.
Aunque cabe señalar que estos dos modelos son bastante básicas y hacen suposiciones acerca de cuántas personas pueden estar en un matrimonio;)
Aquí es un esquema hipotético que puede utilizar. Todas las personas están en una sola mesa y cada persona tiene una identificación única. Los matrimonios están en una tabla de relaciones, con claves foráneas.
PERSONS
- ID - INTEGER, PK
- FIRSTNAME - VARCHAR(20)
- LASTNAME - VARCHAR(20)
- SEX - CHAR(1)
- ... any other fields
MARRIAGES
- PERSON1_ID - INTEGER, FK
- PERSON2_ID - INTEGER, FK
- MARRIAGE_DATE - DATE
- ANULLMENT_DATE - DATE
- ... any other fields
nice - excepto que el uso del verbo annullment es arbitrariamente restrictivo ... iría con begin_dt y end_dt y tal vez un atributo end_reason en otro lado si fuera necesario. – Randy
Esto suena como un uso para una búsqueda sencilla mesa- la parte importante es tener dos campos, uno una clave externa para el campo ID de Persona1 la otra una clave externa para el campo ID de Person2. Cualquier detalle sobre el matrimonio (fechas, si todavía está vigente, etc.) también se almacenaría en esta tabla.
Eso facilitaría que las personas tuvieran matrimonios múltiples, relaciones polígamas, etc. Si desea una relación simple de 1: 1, podría incluir una referencia de clave externa al cónyuge en el campo de persona, pero sería considerablemente menos flexible.
Esta es una gran pregunta para la enseñanza del diseño de esquemas. Lo que parece ser un problema simple puede fácilmente llegar a ser bastante complicado:
Por ejemplo, cómo manejar:
- mariages de más de dos personas
- tipos diferentes de unión (legal, religiosa, otros)
- matrimonios simultáneos
- matrimonios repetición
- divorcio
- auto-matrimonio (ojo, que sucedió en Glee!)
El truco, si es que existe, es pensar cuidadosamente todas las permutaciones de lo que usted está tratando de modelo. Solo entonces sigues adelante y lo modelas.
también, es posible que necesite almacenar la información detallada del historial, pero también necesita una forma efectiva de obtener el cónyuge actual de cualquier persona de arbtirary, que puede necesitar alguna infraestructura adicional ... diversión :) – araqnid
No creo que pueda confiar en una base de datos para guardar su matrimonio; D – glenatron
2 tablas. Una relación de uno a uno con una tabla de asociación. –
"¡Señoras y señores de Glenatron! Él estará aquí todo el fin de semana, ¡no olviden darle propina a sus camareros y camareras!" –