Pregunta

Una de las cosas que me confunde sobre ERD es si hacen cualquier receta acerca de cómo sus relaciones deben ser implementados tecnológicamente.

En el siguiente diagrama No estoy seguro de si el esquema requiere estas relaciones para ser implementadas a nivel de base de datos o en el nivel de aplicación.

¿Está haciendo las recetas tecnológicas o simplemente definir la relación y dejando a mí decidir cómo ponerlo en práctica?

¿Me necesita tener más información del creador de la ERD antes de construir algo que se basa en ella?

alt text

¿Fue útil?

Solución

Un ERD no es una "receta tecnológica" como usted dice, sino simplemente una representación de las relaciones lógicas.

¿Cómo ponerlo en práctica - en la base de datos o la aplicación - depende de usted

.

Sin embargo, la base de datos es el lugar adecuado para hacer cumplir estas relaciones.

Otros consejos

Parece que está girando el problema al revés.

La respuesta es, por supuesto: no, no hay nada que le obligará a crear relaciones en la base de datos. Pero ¿por qué no hacerlo?

Es por eso que la base de datos se llama base de datos relacional - porque le ofrece una solución para esta misma pregunta que está fácilmente disponible, bien integrada con las herramientas y las capas de persistencia, y sus consecuencias para los desarrolladores de aplicaciones están bien entendido.

Sería una locura no implementar las relaciones a nivel de base de datos.

Un diagrama de ERD es un diagrama lógico que muestra las relaciones entre entidades y su cardinalidad aunque puede interpretarse como un diagrama de relación de tabla o un diagrama de clases al mismo tiempo, sin embargo, es que ninguno de ellos y todavía se necesitarán los otros diagramas.

Por cierto, por lo que yo sé que siempre es bueno tener relaciones forzadas en su modelo de base de datos para mantener la consistencia de la base de datos.

Yo diría que sea tan redundante como sea posible cuando se trata de validar los datos de su puesta en su base de datos.

Hacer revisiones en el lado de aplicación para asegurarse de que uniquness tipo de datos / validez es todo bien. Y la estructura de la base de datos para tener todas las relaciones que necesita.

No se limite a dejar que la base de datos / aplicaciones asuma que todo está correcto.

Esto le puede ahorrar varias horas de fijar registros huérfanos y las cuestiones de consistencia.

"¿Está haciendo las recetas tecnológicas ..."

No se ve como el código. Tal vez me falta algo.

"o simplemente definir la relación y dejando a mí decidir cómo ponerlo en práctica?"

Eso depende de su cliente.

Si creen que el diagrama es isomorfo al código, entonces usted tiene que entender las piezas que faltan de convención o contexto.

Si no creen que el diagrama es isomorfo al código, entonces usted tendrá que decidir cómo ponerlo en práctica.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top