¿Usando un ORM o SQL simple? [cerrado]
Para algunas de las aplicaciones que desarrollé (y luego me olvidé), he estado escribiendo SQL simple, principalmente para MySQL. Aunque he usado ORM en Python como SQLAlchemy , no los usé por mucho tiempo. Por lo general, era la documentación o la complejidad (desde mi punto de vista) lo que me frenaba.
Lo veo así: use un ORM para portabilidad, SQL simple si solo va a usar un tipo de base de datos. Realmente estoy buscando consejos sobre cuándo usar un ORM o SQL al desarrollar una aplicación que necesita soporte de base de datos.
Pensándolo bien, sería mucho mejor usar simplemente un contenedor liviano para manejar las inconsistencias de la base de datos en lugar de usar un ORM.
Hablando como alguien que pasó bastante tiempo trabajando con JPA (Java Persistence API, básicamente la API ORM estandarizada para Java/J2EE/EJB), que incluye Hibernate, EclipseLink, Toplink, OpenJPA y otros, compartiré algunos de mis observaciones.
- Los ORM no son rápidos. Pueden ser adecuados y la mayoría de las veces lo adecuado está bien, pero en un entorno de alto volumen y baja latencia son un no-no;
- En lenguajes de programación de propósito general como Java y C# se necesita mucha magia para hacerlos funcionar (por ejemplo, tejido del tiempo de carga en Java, instrumentación, etc.);
- Cuando utilice un ORM, en lugar de alejarse más de SQL (que parece ser la intención), se sorprenderá de cuánto tiempo dedica a modificar XML y/o anotaciones/atributos para que su ORM genere SQL de alto rendimiento;
- Para consultas complejas, realmente no hay sustituto. Al igual que en JPA, hay algunas consultas que simplemente no son posibles y que están en SQL sin formato y cuando tienes que usar SQL sin formato en JPA no es bonito (C#/.Net al menos tiene tipos dinámicos, var, que es mucho mejor que una matriz de objetos);
- Hay una gran cantidad de "errores" al usar ORM. Esto incluye comportamientos no intencionados o inesperados, el hecho de que tiene que incorporar la capacidad de realizar actualizaciones SQL en su base de datos (mediante el uso de refresco() en JPA o métodos similares porque JPA almacena todo en caché de forma predeterminada para que no detecte una base de datos directa). actualización: ejecutar actualizaciones directas de SQL es una actividad común de soporte de producción);
- La discrepancia entre objetos y relaciones siempre causará problemas. En cualquier problema de este tipo existe un equilibrio entre la complejidad y la integridad de la abstracción. A veces sentí que JPA fue demasiado lejos y alcanzó una ley real de rendimientos decrecientes donde la complejidad no estaba justificada por la abstracción.
Hay otro problema que requiere un poco más de explicación.
El modelo tradicional para una aplicación web es tener una capa de persistencia y una capa de presentación (posiblemente con servicios u otras capas intermedias, pero estas son las dos importantes para esta discusión). Los ORM fuerzan una vista rígida desde su capa de persistencia hasta la capa de presentación (es decir, sus entidades).
Una de las críticas a los métodos SQL más básicos es que terminas con todos estos VO (objetos de valor) u DTO (objetos de transferencia de datos) que se utilizan en una sola consulta. Esto se promociona como una ventaja de los ORM porque te deshaces de eso.
La cuestión es que esos problemas no desaparecen con los ORM, simplemente suben a la capa de presentación. En lugar de crear VO/DTO para consultas, crea objetos de presentación personalizados, normalmente uno para cada vista. ¿Cómo es esto mejor? En mi humilde opinión, no lo es.
He escrito sobre esto en ORM o SQL: ¿Ya llegamos a ese punto? .
Mi tecnología de persistencia preferida (en Java) en estos días es ibatis. Es una envoltura bastante delgada alrededor de SQL que hace más del 90% de lo que JPA puede hacer (incluso puede realizar una carga diferida de relaciones aunque no está bien documentada) pero con mucha menos sobrecarga (en términos de complejidad y código real).
Esto surgió el año pasado en una aplicación de GWT que estaba escribiendo. Mucha traducción de EclipseLink a objetos de presentación en la implementación del servicio. Si estuviéramos usando ibatis, habría sido mucho más sencillo crear los objetos apropiados con ibatis y luego pasarlos hacia arriba y hacia abajo en la pila. Algunos puristas podrían argumentar que esto es Bad™. Tal vez sea así (en teoría), pero les digo una cosa: habría llevado a un código más simple, una pila más simple y más productividad.
Los ORM tienen algunas características interesantes. Pueden manejar gran parte del trabajo duro de copiar columnas de bases de datos a campos de objetos. Por lo general, se encargan de convertir los tipos de fecha y hora del idioma al tipo de base de datos apropiado. Por lo general, también manejan relaciones de uno a muchos con bastante elegancia al crear instancias de objetos anidados. Descubrí que si diseña su base de datos teniendo en cuenta las fortalezas y debilidades del ORM, le ahorra mucho trabajo al ingresar y sacar datos de la base de datos. (Querrá saber cómo maneja el polimorfismo y las relaciones de muchos a muchos si necesita mapearlas. Son estos dos dominios los que proporcionan la mayor parte del "desajuste de impedancia" que hace que algunos llamen a ORM el "vietnam de la informática". .)
Para las aplicaciones que son transaccionales, es decir, usted realiza una solicitud, obtiene algunos objetos, los recorre para obtener algunos datos y los representa en una página web, la tasa de rendimiento es pequeña y, en muchos casos, ORM puede ser más rápido porque almacenará en caché los objetos que visto antes, que de otro modo habría consultado la base de datos varias veces.
Para las aplicaciones que generan muchos informes o que manejan una gran cantidad de filas de bases de datos por solicitud, el impuesto ORM es mucho más pesado y el almacenamiento en caché que realizan se convierte en una carga grande e inútil que acapara la memoria. En ese caso, el camino a seguir es un mapeo SQL simple (LinQ o iBatis) o consultas SQL codificadas a mano en un DAL delgado.
Descubrí que para cualquier aplicación a gran escala utilizará ambos enfoques. (ORM para CRUD sencillo y SQL/DAL delgado para informes).
Digo SQL simple para lecturas , ORM para CUD .
El rendimiento es algo que siempre me preocupa, especialmente en las aplicaciones web, pero también la mantenibilidad y legibilidad del código. Para abordar estos problemas escribí SqlBuilder .
