¿Funciona el mapeo relacional de Relational de Object a Relational?

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 se utiliza un lenguaje funcional, tiene el mismo problema presentarse a sí misma? 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.

cualquier persona tiene opiniones o ideas interesantes? ¿Cuál es el estado de la industria?

Answer 1

Los problemas difíciles de ampliar la base de datos relacional son transacciones extendidas, desajustes de tipos de datos, traducción automatizada de consultas y cosas como N+1 Select que son problemas fundamentales para abandonar el sistema relacional y, en mi opinión, no cambian cambiando el paradigma de la programación receptora.

Answer 2

supongo funcional para el mapeo relacional 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 3

me gustaría pensar que, como se ha mencionado Sam, si la base de datos debe ser actualizada, los mismos problemas de concurrencia tienen que hacer frente como con el mundo OO. 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 la lectura, el lenguaje funcional podría ser más natural con algunos dominios de problemas (como parece ser, independientemente de la DB)

El < funcional - mapping> RDBMS no debería tener grandes diferencias a la OO < - > Mapeos 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 contra un esquema DB heredado, etc.

por ejemplo, la recuperación perezosa, etc. para asociaciones, probablemente podría implementarse bastante bien con algunos conceptos relacionados con la evaluación diferida. (A pesar de que se pueden hacer muy bien con OO también)

Editar: Con algunas google he encontrado (biblioteca de SQL para Haskell) HaskellDB - que podría valer la pena?

Answer 4

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

Es bastante común que comenzar con un conjunto de datos, hacer algún cálculo complejo en él, 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. Usted termina teniendo otra mesa, duplicando las claves, pero ya no necesita desperdiciar espacio en las columnas que almacenan NULL –, solo almacena lo que tiene. Luego, une tus resultados en tu selección final.

I (ab) utilizaron un RDBMS de esta manera y terminó escribiendo sentencias SQL que se veía sobre todo como esto ...

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 en esencia es la creación de un grupo de fijaciones 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.

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

Una ventaja 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 sus necesidades

1. Si desea centrarse en las estructuras de datos, utilizar un ORM como JPA/Hibernate
2. Si desea arrojar luz sobre los tratamientos, echar un vistazo a FRM bibliotecas: QueryDSL o Jooq
3. Si tienen que ajustar sus requerimientos SQL en bases de datos específicas, utilizan JDBC y SQL nativo solicita

El strengh de diversas tecnologías "mapeo relacional" es la portabilidad: se asegura que su aplicación se ejecutará en la mayoría de las bases de datos de ACID. De lo contrario, lidiará con las diferencias entre varios dialectos SQL cuando escriba manualmente las solicitudes SQL.

Por supuesto que puede contenerse con el estándar SQL92 (y luego hacer algo de programación funcional) o se puede reutilizar algunos conceptos de la programación functionnal con ORM marcos

Los strenghs 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 los objetos java y las filas de su 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 son también sus puntos débiles:

1. La sesión debe ser capaz de comparar objetos por lo que necesita es igual a métodos implementos/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 se basa en 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 de negocio. 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 ... Luego debe implementar la igualdad de objeto 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 vuelve a una lista simple en la que tiene que repetir (y se producen problemas de rendimiento).

3. Las API de ORM a veces no son aptas para el uso en el mundo real. Por ejemplo, las aplicaciones web del mundo real intentan forzar el aislamiento de la sesión agregando algunas cláusulas "DONDE" cuando obtiene datos ... Luego, el "Session.get (id)" no es suficiente y debe pasar a una configuración más compleja DSL (HSQL, Criteria API) o volver a SQL nativo

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

En el otro lado , FRM es una compensación entre "Asignación 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.

• Object Relational Mapping faculta el uso de "objetos de dominio rico", que son clases Java cuyos estados son mutables durante la transacción de base de datos
• Mapeo Relacional funcional se basa en "Objetos Pobre de dominio", que son inmutables (tanto usted tiene que clonar uno nuevo cada vez que se quiere alterar su contenido)

libera las restricciones impuestas a la sesión de ORM y se basa la mayor parte de tiempo en un DSL sobre el SQL (por lo que la portabilidad no importa) Pero, por otro lado, debe observar los detalles de la transacción, la concurrencia y emite

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