ORM: ¿el esquema de base de datos maneja la composición de la entidad o viceversa?

Hemos tenido bastante debate entre nuestro grupo de desarrollo sobre si la composición de las entidades debe impulsar el diseño de la base de datos, o si el diseño de la base de datos debe conducir la composición de las entidades.ORM: ¿el esquema de base de datos maneja la composición de la entidad o viceversa?

Para aquellos que han tratado con esto, ¿cuál ha sido su filosofía? Por supuesto, no todas las entidades asignan 1: 1 a una tabla de base de datos. Pero, para aquellos que lo hacen, ¿cómo has manejado esto? IOW, que viene primero, ¿la tabla de la base de datos y luego una entidad correspondiente o una entidad y luego una tabla de base de datos para persistir?

Gracias.

Fuente

2010-02-14 Randy Minder

La misma pregunta: http://stackoverflow.com/questions/919880/code-first-or-database-first-how-to- choose –

Su base de datos probablemente sobrevivirá a cualquier aplicación que construya hoy. Todo el rendimiento y la escalabilidad serán impulsados por el esquema de su base de datos. Un modelo de base de datos sólida es la base sobre la que se basa cualquier aplicación, y yo diría que es donde debe invertir más esfuerzo en el diseño y las pruebas, ya que le dará los mayores beneficios.

Dicho esto, por supuesto, su aplicación se prefiere para manipular entidades del dominio y la manipulación de entidades no naturales impulsados por la teoría relacional en contraposición a las entidades de negocio se acaba de complicar las cosas. Mi punto de vista es que es el papel de ORM para que coincida con los dos, de la mejor manera posible. Pero cada vez que aparecen conflictos inevitables, el derecho de paso debe estar dado por el factor determinante de su rendimiento y escalabilidad: el esquema de la base de datos.

Fuente

2010-02-14 06:00:12

@Remus - Creo que esta es una muy buena perspectiva, y una que realmente no había pensado. La base de datos, y los datos en ella, probablemente sobrevivirán a las aplicaciones iniciales que le mantienen datos. Y se usará potencialmente de muchas maneras distintas a la aplicación que persista en sus datos. –

Diría que construyes tu modelo de datos lógicos y construyes la base de datos y los objetos correspondientes a eso.

De hecho, me gustaría cuestionar la suposición de que la tabla de base de datos y las entidades correspondientes no pueden correspondiente. Pocas veces he visto un caso en el que realmente no pudieran (si estás construyendo una aplicación desde cero). Además, diría que cada vez que el modelo de objetos y el esquema de la base de datos divergían, presentaba muchos problemas. Sin embargo

he vuelto en torno a la idea de que todo es más simple si los haces siempre coinciden, herético que puede ser.

Fuente

2010-02-14 02:43:21

Aún no he visto una traducción directa de un enlace (many- to-many) tabla. En general, se implementan como atributos Vectors/ArrayLists del objeto principal en lugar de su propia clase. –

@OMG Ponies: no hay traducción directa de una tabla de asociación porque la tabla de asociación no es una parte de primera clase del modelo de entidad.La tabla de enlaces extra es parte de un hack estándar para hacer que un modelo relacional represente relaciones de objetos más sofisticadas. –

@ S.Lott: Se denominan bases de datos "Relacionales", no "orientadas a objetos". Las tablas de enlaces no son entidades comerciales, pero la asignación a Vector/ArrayList/Collection/etc sigue siendo un objeto equivalente. –

"entidad y luego una tabla de base de datos a que persisten"

la entidad es lo que manipula su programa. Esa es la esencia de lo que se está procesando.

La representación de base de datos de esa entidad (como representaciones de archivos planos o representaciones GUI) son representaciones simplemente práctico de la entidad.

Es posible que tenga que pensar un poco acerca de la representación DB cuando se trata de ciertas cosas que bases de datos relacionales son particularmente mala en. Las relaciones de muchos a muchos, por ejemplo, requieren la introducción de una tabla adicional porque la base de datos tiene limitaciones que su modelo de objetos no tiene. Es posible que tenga algunas consideraciones de diseño de la entidad para hacer frente a esto, pero esos pocos y bien entendidos.

La base de datos es menos importante.

Las definiciones de Entidad son centrales y esenciales.

Fuente

2010-02-14 02:50:21

Interesante perspectiva. Las opiniones sobre esto parecen estar en todo el mapa. El padre de ORM, Dr. Raymond Chen, sobre el cual se construye LLBLGen, toma el punto de vista opuesto directo. La base de datos maneja las entidades. Ver: http://wagnerblog.com/2009/10/llblgen-linq-nhibernate-an-embarrassment-of-riches/ –

@Randy Minder: Es una lógica simple. El programa de aplicación realmente hace el trabajo real del sistema actual. Todo lo demás es presentación o persistencia. Las referencias de Chen son muy difíciles de rastrear. La entrada anterior del wagnerblog hace referencia a Peter Chen. El blog de Raymond Chen no menciona mucho al ORM. Como una cuestión práctica, los objetos importan; la base de datos es solo persistencia. –

También estoy de acuerdo con esta respuesta. Otro aspecto importante es que el esquema de la base de datos contiene solo algunos aspectos relacionados con la operación de la entidad esperada, es decir, de todos modos necesita anotaciones adicionales que describan cosas tales como la carga diferida, el comportamiento de asociación, etc. El hecho de que la base de datos generalmente dure más tiempo que la aplicación no significa que deba diseñarla primero, si la herramienta permite simplemente generarla. Así que también busco en la base de datos como en una representación de almacenamiento particular. –

ORM: ¿el esquema de base de datos maneja la composición de la entidad o viceversa?

Respuesta

Cuestiones relacionadas