¿De dónde caen a través de ORM?

Question

A menudo oigo golpear ORM por ser inflexible y una "abstracción con fugas", pero que realmente no lo oyen ¿Por qué Son problemáticos. Cuando se utiliza correctamente, ¿qué son exactamente las faltas de ORM? Lo pregunto porque estoy trabajando en un ORM PHP y me gustaría para que pueda resolver los problemas que una gran cantidad de otros ORM fallar en, como carga lenta y la falta de subconsultas.

Por favor, sea específico con sus respuestas. Muestra algo de código o describir un esquema de base de datos donde un ORM luchas. No importa el idioma o el ORM.

Answer 1

Uno de los problemas más grandes que he notado con todos los ORM que he utilizado está actualizando sólo unos pocos campos sin recuperar el objeto en primer lugar.

Por ejemplo, decir que tengo un objeto Project asignada en mi base de datos con los siguientes campos: id, nombre, descripción, owning_user. Por ejemplo, a través de ajax, quiero actualizar sólo el campo de descripción. En la mayoría de ORM la única manera para mí para actualizar la tabla de base de datos, mientras que sólo tener una identificación y descripción valores es recuperar ya sea el objeto del proyecto de la base de datos, establecer la descripción y luego enviar la parte posterior objeto a la base de datos (lo que requiere dos operaciones de base de datos sólo por una simple actualización) o para actualizarla a través de procedimientos almacenados (que es el método que uso actualmente).

Answer 2

Los objetos y registros de la base realmente no son tan similares. Se han introducido espacios que puedes almacenar cosas, pero eso es todo. Bases de datos tienen una noción completamente diferente de la identidad de los lenguajes de programación. Ellos no pueden manejar objetos compuestos, así que usted tiene que utilizar tablas adicionales y las claves externas en su lugar. La mayoría tienen ningún concepto de tipo de herencia. Y la forma natural para navegar por una red de objetos (seguir algunos de los punteros en un solo objeto, conseguir otro objeto, y eliminar la referencia de nuevo) es mucho menos eficiente cuando mapeado en el mundo de base de datos, ya que hay que hacer varios viajes de ida y recuperar lotes de datos que no le importaba.

En otras palabras: la abstracción no se puede hacer muy bien en el primer lugar; no son las herramientas ORM que son malas, pero la metáfora que implementen. En lugar de un isomorfismo perfecto, que es sólo una semejanza superficial, por lo que la tarea en sí no es una muy buena abstracción. (Todavía es mucho más útil que tener que entender las bases de datos íntimamente, sin embargo. El desprecio de herramientas ORM vienen en su mayoría de los administradores de bases mirando hacia abajo en meros programadores.)

Answer 3

ORM también puede escribir código que no es eficiente. Puesto que el rendimiento de base de datos es fundamental para la mayoría de los sistemas, pueden causar problemas que podrían haberse evitado si un ser humano escribió el código (pero que no podría haber sido mejor si el humano en cuestión no comprendía la optimización del rendimiento de base de datos). Esto es especialmente cierto cuando la consulta se complejiza.

Creo que mi mayor problema con ellos es que aunque por abstraerse de los detalles, los programadores junior están recibiendo menos comprensión de cómo escribir consultas que necesitan para ser capaz de manejar los casos de borde y los lugares en los que el ORM escribe realmente mal código. Es realmente difícil de aprender el material avanzado cuando usted nunca tuvo que entender los conceptos básicos. Un ORM en manos de alguien que entiende y se une por grupo y consulta avanzada es una cosa buena. En las manos de alguien que no entiende el álgebra de Boole y se une y un montón de otros conceptos básicos de SQL, es una cosa muy mala que resulta en muy mal diseño de base de datos y consultas.

bases de datos relacionales son no objetos y no debe ser tratado como tal. Tratando de hacer un águila en un bolso de seda generalmente no tiene éxito. Es mucho mejor para aprender lo que el águila es bueno y por qué y dejar que la mosca de águila, que tener una mala bolso y un águila muerta.

Answer 4

La forma en que veo que es así. Para utilizar un ORM, usted tiene que por lo general pila varias funciones php, y luego se conecta a una base de datos y, esencialmente, todavía ejecuta una consulta MySQL o algo similar.

¿Por qué toda la extracción de entre el código y la base de datos? ¿Por qué no podemos simplemente usar lo que ya sabemos? Normalmente un desarrollador web sabe su lengua backend, su lengua db (una especie de SQL), y una especie de idiomas frontend, como HTML, CSS, JS, etc ...

En esencia, estamos tratando de añadir una capa de abstracción que incluye muchas funciones (y todas las funciones de php sabe puede ser más lenta que la asignación de una variable). Sí, esto es un cálculo micro, pero aún así, se suma.

No sólo tenemos ahora tienen varias funciones que pasar, pero también tenemos que aprender cómo funciona la ORM, por lo que hay cierta pérdida de tiempo allí. Pensé que la idea de la separación de código era mantener su código por separado a todos los niveles. Si estás en el mundo LAMP, basta con crear la consulta (que debe saber MySQL) y utilizar la funcionalidad ya existente php para comandos preparados. HECHO!

LAMPARA FORMA:

• Crear consulta (cadena);
• uso mysqli preparó declaraciones y recuperar datos en una matriz.

ORM MANERA:

• ejecutar una función que obtiene la entidad
• que se ejecuta una consulta de MySQL
• ejecutar otra función que añade un condicional
• ejecutar otra función que añade otra condicional
• ejecutar otra función que se une a
• ejecutar otra función que añade condicionales en la unión
• ejecutar otra función que prepara
• se ejecuta otra consulta MySQL
• ejecutar otra función que recoge los datos
• corre otra MySQL Query

¿Alguien más tiene un problema con la pila ORM? ¿Por qué nos estamos convirtiendo dichos desarrolladores perezosos? Más o menos creativo que estamos dañando nuestro código? Si no está roto, no lo arregles. A su vez, reparar su equipo de desarrollo para comprender los fundamentos de la web dev.

Answer 5

ORM están tratando de resolver un problema muy complejo. Hay casos borde abundancia y de las principales ventajas y desventajas de diseño sin soluciones claras o evidentes. Al optimizar un diseño ORM para la situación A, que intrínsecamente lo hace incómodo para resolver la situación B.

Hay ORM que manejan la carga diferida y subconsultas de una manera "suficientemente bueno", pero es casi imposible de obtener de "suficientemente bueno" a "grande".

Al diseñar su ORM, usted tiene que tener un mango bastante bueno en toda la base de datos de posibles diseños incómoda se espera que su ORM de manejar. Usted tiene que hacer concesiones en torno al cual explícitamente situaciones que están dispuestos a manejar torpemente.

Yo no se ven en el ORM como inflexibles o más fugas que no sea su abstracción compleja promedio. Dicho esto, ciertos ORM son mejores que otros en esos aspectos.

Buena suerte reinventar la rueda.