Sobre persistencia
Saludos comunidad!
Tenia dudas al respecto de si poner este tema o no, dado que no tiene que ver directamente con Java. En si me gustaría que fuera una retroalimentación, no es una duda, simplemente quisiera saber sus experiencias ya que han surgido algunos debates con ciertos compañeros y me gustaría conocer sus puntos de vista.
El punto es: "La programación del lado del DBMS"
Muchos dicen que es mejor hacer toda la capa de persistencia con programación en el DBMS(Sql server, Postgres, MySql, Oracle), es decir, utilizando "Functions" y "Stored Procedures", si quieres hacer un insert, has tu función o tu SP para que le mandes los parametros y los inserte, si quieres actualizar igual, si quieres eliminar también, si tienes consultas un poco más elaboradas que un Select mejor hazlas con un SP o una función que ya te retorne todo. El argumento es que se deja toda la chamba al DBMS y como lo más seguro es que sea un servidor dedicado pss tendrá un mejor rendimiento.
Están los que dicen que es mejor implementar toda la capa de persistencia con el propio lenguaje de programación en cuestión, utilizando obviamente tecnologías modernas como el mapeo ORM, en el caso de Java por citar uno sería Hibernate. Es decir, que tanto los inserts, como deletes y updates los hagas desde el lenguaje de programacion (Hibernate y Java pues), así como también las consultas.
Yo creo que los que defienden la primera opción tienen razón en cierta medida, quizá el rendimiento pueda ser un poco mejor, pero hasta que punto se puede llegar a abusar de esto?, porque he conocido personas que hasta un simple select lo quieren meter a una funcion o un sp. Por otro lado, con la llegada de los ORM se dice que está más conceptualizado porque todo lo piensas en objetos, también se comenta que el rendimiento por ejemplo de Hibernate es muy bueno, incluso superior a JDBC sólito, pero igual, creo que utilizar puro Hibernate descartas muchas de las bondades que te da la programación del lado del DBMS.
Y es el gran dilema que se tiene, que es mejor? yo creo que un equilibrio es lo mejor, pero como saber cuando estas en equilibrio y cuando no? cuando o para que tipo de necesidades te inclinas por uno o por el otro?
Ustedes que opinan?
- Inicie sesión o regístrese para enviar comentarios
Pros y cons
Como siempre, hay ventajas y desventajas de cada enfoque. Si dejas que todo mundo haga lo que quiera con el ORM, después el servidor de base de datos está arrastrándose porque alguien decidió hacer una consulta a una tabla de millones de registros, usando columnas no indexadas, sin ponerle límite... se acaban además la memoria del contenedor JEE, etc.
Si dejas todo en funciones y SP's en el DBMS entonces te evitas esas broncas porque tienes gente que le sabe muy bien al DBMS y es la que hace todas esas funciones y SP's, no necesariamente los programadores. Ya no tendrás problemas de performance. Pero se vuelve una burocracia; las discusiones con el DBA son interminables porque el cliente pidió un reporte que el programador le pide al DBA y el DBA dice que no porque va a causar un problema y se pone necio con que no se va a hacer y ya; el programador no tiene otra opción que darle la vuelta y empezar a hacerlo directo con el ORM o JDBC o lo que sea.
Luego resulta que hay que modificar un reporte y pues hay que moverle en el software en Java y hay que moverle al SP o función que lo hace. Ya no es un cambio en un lugar sino en dos, y tienes que ser muy cuidadoso con eso porque luego no sabes ni por qué no funciona.
IMHO JDBC ya está bastante optimizado, al grado que la ventaja de usar puro SP y funciones en DBMS no representa una diferencia notable en performance. Si optimizas bien en JDBC con PreparedStatements y cosas así no deberías tener broncas. Hibernate maneja un cache de objetos lo cual también te puede evitar viajes enteros a la DBMS.
Tienes mucha razón,
Tienes mucha razón, recuerdo que un amigo me dijo que en su empresa utilizaban Sql Server y que muchas cosas las hacían con puro "Transact - sql" (Lenguaje de programación de Sql Server), y que un día quisieron migrar a Oracle y que ya les andaba, en primera porque el lenguaje de Oracle (Pl/Sql) tenia distinta sintaxis a Transact-sql y pues para migrar todos los SP y Functions sería un cuete, y otro detalle creo que en Oracle los nombres para las tablas y otros objetos no pueden sobrepasar los 30 caracteres, corrijanme si me equivoco, pero que ahí tuvieron otro problema y por lo tanto tuvieron que seguir con Sql Server.
Stored Procedures
Yo tomo la opción de crear Stored Procedures cuando:
Los SPs aumentan la complejidad de un proyecto (como cualquier tecnología que se agregue), también tienen la desventaja de la portabilidad en caso de cambiar de RDBMS (que ya mencionaste). Tienen la ventaja de que el rendimiento está asegurado, ya que estás haciendo las cosas en la misma BD antes de llevarlas a la aplicación y cuando te lleves los datos resultantes a la aplicación posiblemente ya serán menos datos (esto en caso de que debas manipular antes de mostrar).
Los ORM tienen la ventaja de abstraer la complejidad y hacer como si todo fuera objetos, la desventaja es que (aún) están limitados en cuanto a algunas cosas (por ejemplo no hay soporte completo para SPs) y el rendimiento no es tan bueno como con JDBC o SPs.
Con JDBC puro obtienes rendimiento y complejidad media, o mejor dicho talacha por si tienes que manipular un volumen considerable de datos.
Para cada situación podría aplicar diferente carta, si quieres rapidez en el desarrollo y no importa demasiado el performance la opción podría ser algún ORM, si requieres que tu aplicación esté super depurada en cuanto a performance podría ser JDBC o SPs, aunque el tiempo de desarrollo se dispare y la mantenibilidad decaiga un poco. Ya depende mucho de qué te conviene más en cada caso.
Saludos.