database - estructura - modelo transitorio odoo

¿Es el mapeo funcional al relacional más fácil que el objeto a relacional?

Question

La asignación relacional de objetos se ha debatido ampliamente, incluso aquí. Tengo experiencia con algunos enfoques y las trampas y compromisos. La verdadera resolución parece que requiere cambios en el OO o en los modelos relacionales.

Si usa un lenguaje funcional, ¿se presenta el mismo problema? Me parece que estos dos paradigmas deberían encajar mejor que OO y RDBMS. La idea de pensar en conjuntos en un RDBMS parece encajar con el paralelismo automático que los enfoques funcionales parecen prometer.

¿Alguien tiene opiniones o puntos de vista interesantes? ¿Cuál es el estado de la industria?

Answer 1

Creo que el mapeo relacional funcional debería ser más fácil de crear y usar que OO a RDBMS. Siempre que solo consulte la base de datos, eso es. Realmente no veo (todavía) cómo podría hacer actualizaciones de bases de datos sin efectos secundarios de una manera agradable.

El principal problema que veo es el rendimiento. Los RDMS de hoy no están diseñados para ser utilizados con consultas funcionales, y probablemente se comporten mal en bastantes casos.

Answer 2

Creo que, como mencionó Sam, si la base de datos debe actualizarse, deben enfrentarse los mismos problemas de concurrencia que con OO World. La naturaleza funcional del programa podría ser incluso un poco más problemática que la naturaleza del objeto debido al estado de los datos, las transacciones, etc. del RDBMS.

Pero para leer, el lenguaje funcional podría ser más natural con algunos dominios problemáticos (como parece ser independientemente del DB)

El mapeo <-> RDBMS funcional no debe tener grandes diferencias con las asignaciones de OO <-> RDMBS. Pero creo que eso depende mucho del tipo de tipos de datos que desee usar, si desea desarrollar un programa con un nuevo esquema de base de datos o hacer algo en contra de un esquema DB heredado, etc.

Por ejemplo, las búsquedas de pereza, etc. para asociaciones, probablemente podrían implementarse bastante bien con algunos conceptos relacionados con la evaluación diferida. (Aunque también se pueden hacer muy bien con OO)

Editar: Con un poco de Google encontré HaskellDB (biblioteca de SQL para Haskell), ¿podría valer la pena intentarlo?

Answer 3

Los problemas difíciles de extender la base de datos relacional son las transacciones extendidas, los desajustes de datos, la traducción automática de consultas y cosas como N + 1 Select que son problemas fundamentales para abandonar el sistema relacional y, en mi opinión, no cambian al cambiar el recibiendo el paradigma de programación.

Answer 4

No he hecho el mapeo funcional-relacional, per se , pero he usado técnicas de programación funcional para acelerar el acceso a un RDBMS.

Es bastante común comenzar con un conjunto de datos, realizar cálculos complejos y almacenar los resultados, donde los resultados son un subconjunto del original con valores adicionales, por ejemplo. El enfoque imperativo dicta que usted almacena su conjunto de datos inicial con columnas NULL adicionales, haga su cálculo y luego actualice los registros con los valores calculados.

Parece razonable. Pero el problema con eso es que puede ser muy lento. Si su cálculo requiere otra instrucción SQL además de la consulta de actualización en sí, o incluso debe hacerse en el código de la aplicación, literalmente tiene que (re) buscar los registros que está cambiando después del cálculo para almacenar los resultados en las filas correctas .

Puede evitar esto simplemente creando una nueva tabla para resultados. De esta manera, siempre puede insertar en lugar de actualizar. Terminas teniendo otra mesa, duplicando las claves, pero ya no necesitas desperdiciar espacio en las columnas que almacenan NULL: solo almacenas lo que tienes. Luego, une tus resultados en tu selección final.

Yo (ab) usé un RDBMS de esta manera y terminé escribiendo sentencias SQL que se veían principalmente así ...

create table temp_foo_1 as select ...;
create table temp_foo_2 as select ...;
...
create table foo_results as
select * from temp_foo_n inner join temp_foo_1 ... inner join temp_foo_2 ...;

Lo que esto está haciendo esencialmente es crear un grupo de enlaces inmutables. Lo bueno, sin embargo, es que puedes trabajar en conjuntos completos a la vez. Te recuerda algunos idiomas que te permiten trabajar con matrices, como Matlab.

Me imagino que esto también permitiría el paralelismo mucho más fácil.

Un beneficio adicional es que los tipos de columnas para las tablas creadas de esta manera no tienen que especificarse porque se deducen de las columnas de las que se seleccionan.

Answer 5

Eso depende de tus necesidades

1. Si quiere enfocarse en las estructuras de datos, use un ORM como JPA / Hibernate
2. Si quiere arrojar luz sobre los tratamientos, eche un vistazo a las bibliotecas FRM: QueryDSL o Jooq
3. Si necesita ajustar sus solicitudes de SQL a bases de datos específicas, use JDBC y solicitudes SQL nativas

La fuerza de varias tecnologías de "Mapeo Relacional" es la portabilidad: usted se asegura de que su aplicación se ejecute en la mayoría de las bases de datos de ACID. De lo contrario, lidiará con las diferencias entre varios dialectos de SQL cuando escriba manualmente las solicitudes de SQL.

Por supuesto, puede restringirse al estándar SQL92 (y luego hacer alguna Programación Funcional) o puede reutilizar algunos conceptos de programación funcional con marcos ORM

Las fortalezas de ORM se construyen sobre un objeto de sesión que puede actuar como un cuello de botella:

1. administra el ciclo de vida de los objetos siempre que se esté ejecutando la transacción subyacente de la base de datos.
2. Mantiene un mapeo uno a uno entre sus objetos java y sus filas de base de datos (y utiliza un caché interno para evitar objetos duplicados).
3. detecta automáticamente las actualizaciones de asociación y los objetos huérfanos para eliminar
4. maneja problemas concurrentes con bloqueo optimista o pesimista.

Sin embargo, sus puntos fuertes también son sus debilidades:

1. La sesión debe poder comparar objetos, por lo que debe implementar métodos equals / hashCode. Pero la igualdad de Objetos debe enraizarse en "Business Keys" y no en la base de datos id (¡los nuevos objetos transitorios no tienen ID de base de datos!). Sin embargo, algunos conceptos reificados no tienen igualdad comercial (una operación, por ejemplo). Una solución común depende de los GUID que tienden a molestar a los administradores de la base de datos.

2. La sesión debe espiar los cambios de relación, pero sus reglas de asignación impiden el uso de colecciones inadecuadas para los algoritmos empresariales. En algún momento, le gustaría usar un HashMap, pero el ORM requerirá que la clave sea otro "Objeto de dominio enriquecido" en lugar de otro ligero ... Entonces, debe implementar la igualdad de objetos en el objeto de dominio enriquecido que actúa como clave ... Pero no se puede porque este objeto no tiene contraparte en el mundo de los negocios. Así que vuelves a una lista simple en la que tienes que repetir (y los problemas de rendimiento son el resultado de).

3. La API de ORM a veces no es apta para el uso en el mundo real. Por ejemplo, las aplicaciones web del mundo real intentan imponer el aislamiento de la sesión agregando algunas cláusulas "DONDE" cuando recuperas datos ... Entonces, el "Session.get (id)" no es suficiente y necesitas activar DSL más complejo ( HSQL, Criteria API) o volver a SQL nativo

4. Los objetos de la base de datos entran en conflicto con otros objetos dedicados a otros marcos (como OXM frameworks = Object / XML Mapping). Por ejemplo, si sus servicios REST usan la biblioteca de jackson para serializar un objeto comercial. Pero este Jackson se asigna exactamente a un Hibernate One. Entonces, o fusiona ambos y aparece un fuerte acoplamiento entre su API y su base de datos O debe implementar una traducción y todo el código que guardó desde el ORM se pierde allí ...

Por otro lado, FRM es una compensación entre "mapeo relacional de objetos" (ORM) y consultas SQL nativas (con JDBC)

La mejor manera de explicar las diferencias entre FRM y ORM consiste en adoptar un enfoque DDD.

• La correlación relacional de objetos habilita el uso del "objeto de dominio enriquecido", que son clases de Java cuyos estados son mutables durante la transacción de la base de datos.
• El mapeo relacional funcional se basa en "objetos de dominio pobres" que son inmutables (tanto que debe clonar uno nuevo cada vez que desee modificar su contenido)

Libera las restricciones puestas en la sesión ORM y confía la mayor parte del tiempo en una DSL sobre el SQL (por lo tanto, la portabilidad no importa). Pero, por otro lado, debe examinar los detalles de la transacción, los problemas de concurrencia.

List<Person> persons = queryFactory.selectFrom(person)
.where(
person.firstName.eq("John"),
person.lastName.eq("Doe"))
.fetch();