Bases de Datos - Relación o atributo de entidad.

Hola estimados colegas, tengo una inquietud que deseo evacuar a través de vuestras experiencias. Por lo general en muchos sistemas ERP he visto que tratan a los domicilios, los emails y los teléfonos como entidades separadas, estableciendo relaciones muchos a muchos por ejemplo con una pesona física o natural dependiendo el país donde se modele. De esta manera quedan como clases separadas luego en la aplicación y es menos redundante si en el caso de padrones de afiliados hay personas que comparten dichos datos, solo se deben asociar en vez de agregar nuevos.

Ahora mi consulta es según la experiencia que puedan tener, cómo lo manejan? Porque la realidad es que también es un poco incómodo para desarrollar y su posterior carga, hay que estar manejando modelos de datos por separado en vez de tener todo como atributos. A veces me piden que una empresa o una persona pueda tener más de un teléfono o un domicilio, en ese caso tener como atributo de la entidad me parece un poco innecesario porque siempre van a quedar campos null, aunque alguno que otro tolero no me gusta tener tablas con muchos campos null.

Qué les parece? alguien que pueda aportarme una opinión al respecto?

Muchas gracias y saludos!

Hola Nicolás, en mi opinión, si hay la posibilidad de que haya mas de una dirección por ejemplo, o mas de una cuenta de correo sin saber exactamente la cantidad de ellos, yo siempre pongo una tabla vinculada tal y como hacen los ERPs

No me gusta tener una tabla con campos null... prefiero una tabla vinculada... creo que es mas optimo.

Espero que te sirva... ya me comentaras...

Hola Joel!

Muchas gracias por tu respuesta, coincido y creo que afrontaré así el diseño.

Saludos!

Hola

Desafortunadamente el agregar mas columnas para soportar mas teléfonos o correos en una entidad fuerte rompe la 1era forma normal cuya condición precisamente eliminar grupos repetitivos o multivaluados al atomizar la data. Es por eso que aplicar la 1era y posteriormente la 2da forma normal surgiran estas tablas que asociaran el mismo atributo a una entidad fuerte con una clave compuesta generando con esto una entidad debil a la cual queda enlazada.

Como te habras dado cuenta seguir esto conlleva a generar y mantener nuevas entidades reforzandolas con una integridad referencial, esto lo hace perfectamente el motor de la BD, pero lleva el trabajo adicional del desarrollador elaborar el CRUD necesario para darle mantenimiento y continuidad.

En tiempo recientes el enfoque New SQL es que para minizar este tipo de relaciones que sabemos que deben estar presentes pero que se quieren llevar al mínimo, es usar un tipo de atributo que permita asociar estos valor multivaluados sin agregar atributos adicionales a las entidades.

Te cito el caso de Postgres que permiten manejarlo: Usando arrays, json o xml: Los desarrolladores con los cuales trabajo les gusta mucho usar json o jsonb, porque permite manejar estructuras mas flexibles sin tener que realizar cambios a las entidades. Eso si ellos evitan que algun atributo de esa estructuras depende de alguna entidad debil porque entonces si se complicaria el mantenimiento.

Un ejemplo:

O algo mas complejo:


Es todo

Saludos

Hola Francisco!

Muchas gracias por tu elaborada respuesta! Coincido totalmente como le decía a Joel también, afrontaré el diseño así aunque el desarrollo de los CRUDs sea más complejo pero es mucho más óptimo.

Interesante lo de trabajar con json en la base de datos, ya lo había visto pero no lo apliqué en ningún proyecto, quizá sea hora de empezar a implementar soluciones de este tipo, insertar un json, recuperarlo trabajarlo en la aplicación y volver a guardarlo. Pero en este caso el cliente requiere seguimiento de cada registro en particular así que veo que voy a seguir con la integridad referencial y las tablas de uniones.

Saludos y muchas gracias nuevamente!