Cita: 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.