Cita: Estoy de acuerdo con lo que dices de la tabla "es_hermano_de" pero entonces tendria que asegurarme que TODO este duplicado para que funcione correctamente no?
Es decir, cada vez que se agrega un "hermano" ponerlo de las dos formas en la tabla.
Supongamos, si tenemos usuario "1" y se agrega el usuario "2" y es hermano de 1, en la tabla agregar 2 filas:
2,1
1,2
Si ahora se agrega 3 y es hermano tambien de 1, agregar:
3,1
1,3
3,2
2,3
Eso es una decisión basada en las
reglas del negocio, más que en la lógica de los datos. No se trata de algo mandatorio, aunque resulte
obviamente lógico.
Miralo desde esta óptica: ¿Y si uno de los usuarios
no quiere declarar su parentezco con la otra persona, qué? ¿Lo pondrás de todos modos?
A menos que sea un asunto de administración interna, no puedes. No te olvides que el diseño del modelo de datos no puede exceder los límites del análisis del sistema realizado, es decir, no puedes poner cosas que no hayan sido tomadas del relevamiento, o que no surjan de los requerimientos.
Cualquier duda, hay que consultar al cliente.
Cita: El UPDATE_CASCADE y DELETE_CASCADE funcionaran bien en una tabla asi? si borro/cambio el usuario 1 me borra/cambia tanto el 1,2 como el 2,1?
No hay ninguna razón para que no funcione bien. Absolutamente ninguna. Recuerda que el ON DELETE CASCADE sólo afecta a la tabla Es_Hermano_De... Si el usuario 1 es eliminado, se borra todo registro que lo
vincule con el usuario 2, TODOS. Lo que no se hace es borrar al usuario 2. Eso es tema aparte.