Relacion 1 a 1

[Nexus10]

Hola a tod@s.

Estoy creando una base de datos y he llegado a una relacion 1 a 1 y no se exactamente como mapearla. Tengo las siguientes tablas (entre otras):

provincias: idProv, provincia
zonas: idZona, zona, idProv

Ahora tengo una tabla que es:

mensajes: idMensaje, hora1, texto1, hora2, texto2, hora3, texto3

Se va a generar un mensaje distinto para cada zona, por lo que la relacion entre mensajes y zonas es 1 a 1.
En estos casos, recuerdo que me dijeron en la asignatura de BD de la carrera que lo mejor es unir las dos tablas en una sola, ¿eso sería lo correcto?.
La cosa es que los mensajes van a ir cambiando cada 3 horas, por lo que habrá que hacer muchas actualizaciones y no se si será mejor dejar las dos tablas por separado.
¿Sería mejor dejar una tabla o dos?
Si se dejan dos tablas, ¿habría que poner clave ajena o como sería?

Gracias. Un saludo.

[huesos52]

Cuando se presenta una relación 1 a 1, el campo a relacionar puede ir en cualquiera de las 2 tablas. Si es la única relación, lo mas recomendable es unir las tablas en una sola.

saludos

[Teosanchez]

Creo que lo mejor sería mantenerlas separadas, porque aunque sea una relación 1 a 1 vas a tener repetida muchas veces la información de las zonas.
Mi recomendación es que modeles la relación como si fuera 1 a N.

saludos

[Nexus10]

Si las dejo separadas, entonces sería tal y como lo he puesto en el primer mensaje, ¿no?, es decir, el campo idMensaje sería clave primaria de mensajes y además clave foránea de zonas.
Es que mi duda era si tenía que meter en la tabla mensajes el campo idZona como clave foránea y dejar idMensaje como clave primaria solo, pero claro, ahora veo que sería innecesario porque los dos campos serían el mismo.

Sí, creo que las voy a dejar separadas porque será más fácil las modificaciones.

Gracias. Un saludo.

[gnzsoloyo]

Se va a generar un mensaje distinto para cada zona, por lo que la relacion entre mensajes y zonas es 1 a 1.
En estos casos, recuerdo que me dijeron en la asignatura de BD de la carrera que lo mejor es unir las dos tablas en una sola, ¿eso sería lo correcto?.

Si siempre vas a tener un único mensaje por zona, entonces el mensaje es un atributo de la zona y por tanto debe estar en la zona.
Pero lo que dice Teosanchez es conveniente si existe la posibilidad de que haya zonas sin mensajes o mensajes que tengan campos nulos, por ejemplo. El problema no es de diseño sino de implementación, y es una decisión en donde tienes que valorar los usos que le darás a esos campos y qué tipo de campos usarás.

Por ejemplo: Si esos campos o algunos de ellos son TEXT, BLOB o algo así, y no se llenan siempre, la pregunta es si vale la pena ponerlos con el resto de la info de zona.
Por otro lado, si la mayor parte de las consultas no incluye la lectura de los mensajes, entonces tampoco conviene ponerlos en la misma tabla, ya que afectarán la performance de las búsqueda; no nos olvidemos que cuando se está leyendo una tabla, leer los registros completos es más simple y rápido, pero si debe evitar estos campos el overhead de lectura se incrementa y si estos son demasiado extensos se necesitan más accesos a disco para poder recuperar los otros campos, que son los que se consulta en realidad...
¿Se entiende?

Es decir, trata de mirar el modelo de funcionamiento de esas tablas. Puede que ponerlas por separado termine beneficiando la performance del sistema.