Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
es un típico tema de debate entre los desarrolladores, ya que normalmente hay muchos que prefieren los ORM y hay otros que prefieren a muerte escribir sentencias de SQL directamente en nuestro código.
La verdad es que no hay una opción mejor o peor, ambas son muy buenas, al final ambas te permiten obtenerle la data, pero si cada una de ellas tiene sus puntos a tener en cuenta. Así que eso vamos a platicar el día de hoy.
Bienvenidos sean todos a un episodio nuevo de nuestro podcast Dev&Ops. En este podcast te vamos a tratar de dar la guía para todo lo que es el mundo de tecnología, te atrapamos de dar nuestras experiencias y anécdotas para pues alivinarte un poco la vida en este mundillo que pasa cambiando todos los días, ¿no Douglas? Conmigo, exacto.
Douglas (01:00)
Sí, sí, sí.
Juan (01:01)
Conmigo se encuentra Douglas, ya lo escucharon, es mi co-host para los que es primera vez que nos acompañan, él es un DevOps engineer, bueno, ya tenemos varios episodios explicando que no es la palabra correcta, pero siempre se vuelve mucho más fácil ¿no Douglas? explicarlo de esa manera. ¿Cómo has estado Douglas?
Douglas (01:23)
Bueno, contento de estar con una plática más. No val cien de salud, ¿verdad? Sin embargo, esperaría que lo suficientemente bien como para tener esta plática, esta conversación y poder aportar valor. No quería perdérmelo, ¿verdad? Porque el tema que tenemos hoy me parece muy interesante. Y con lo que dijiste de DevOps Engineer, definitivamente es la forma más fácil de que la gente rapidito se identifique con el rol.
independientemente de que en la práctica no debería de ser un título para un puesto de trabajo, de cualquier manera es más significativo que middle tier administrator, ¿Verdad? Esto es para los que nos escuchan de ya tiempo van a entender la referencia. Entonces, pero sí, a pesar de los problemas de salud, aquí Juan listo para tener esta conversación.
Juan (02:17)
Exacto, sí. Muchas gracias por acompañarnos. Yo creo que eso se merece un like por parte de nuestra audiencia, el hecho de que estés aquí con esos problemitas de salud. Vamos a iniciar entonces para no molestar tu condición.
por mucho tiempo y el tema de hoy Douglas es un tema de Versus. Aquí en el canal tenemos una sección donde ponemos o comparamos diferentes soluciones, tecnologías que son pues pareciera que son antónimos y vemos cuáles son los pros y los contras.
en algunas ocasiones damos nuestra opinión y decimos esta es mejor o esta es peor pero en la realidad cada una de estas herramientas es muy buena dependiendo del caso de uso y lo que intentamos es exponer pues eso no, en que casos pueden ser muy buenas y en que casos tal vez te conviene la otra alternativa así que el día de hoy estamos viendo lo que es ORM versus SQL y bueno
ORM, las tecnologías de ORM obviamente utilizan SQL por detrás, pero aquí cuando decimos SQL nos estamos refiriendo a escribir directamente en el código las sentencias de SQL, el típico insert into la tabla y todo eso.
Y por qué es interesante este tema. Lo que sucede Douglas, te comento que es un típico tema de debate entre los desarrolladores, ya que normalmente hay muchos que prefieren los ORM y hay otros que prefieren a muerte escribir sentencias de SQL directamente en nuestro código.
La verdad es que no hay una opción mejor o peor, ambas son muy buenas, al final ambas te permiten obtenerle la data, pero si cada una de ellas tiene sus puntos a tener en cuenta. Así que eso vamos a platicar el día de hoy. Entonces te voy a comentar Douglas que es un ORM para los que tal vez no estén muy familiarizados.
Yo sé que en tu caso Douglas no programas activamente todos los días pero sé que de buena mano que sabes lo que es un ORM. Pero para explicárselo a nuestra audiencia, un ORM por sus siglas es un Object Relationship Management.
Perdón, relational mapping. Es una herramienta que nos permite ejecutar sentencias de SQL de una manera como si fuesen objetos en el lenguaje de programación. Si tuviésemos, por ejemplo, en JavaScript, podríamos decir algo, no sé, me voy inventar la sintaxis. Database.users.select y eso te daría a los usuarios.
Douglas (04:50)
Mapping, ajá, ajá.
Juan (05:17)
o te permite pues database.users.insert y le das los parámetros ¿Cuál es la ventaja de esto? Me gustaría empezar con la ventaja que yo veo Douglas a ver cómo lo, cómo, qué te parece a vos con los ORMs y creo que por eso se han vuelto muy populares no tenemos tanto espacio a la ambigüedad o a las
tenemos muy claro que es lo que obteniendo, cual es el esquema de la tabla y de la base de datos y tenemos en muchos casos, dependiendo del lenguaje, incluso los tipos de datos ya establecidos. Entonces yo creo que de entrada esa es una de las grandes ventajas de los ORMs porque nos permite pues
tener a simple vista ver todos los objetos que tenemos. Incluso los editores de texto modernos pues tenemos lo que son el autocompletado. Así que al yo escribir database.users y luego punto ya me va a dar las opciones de las diferentes propiedades que se transforman en columnas que podemos seleccionar. Así que esa es una gran ventaja de los ORMs.
que tenemos nuestra base de datos como código y nos permite seleccionar estas cosas. De entrada Douglas, te parece eso? El hecho de poder tener todos los objetos, las tablas como objetos porque cuando hemos hecho queries en SQL normal
pues ya hay muchos editores que te lo facilitan pero cuando estamos escribiendo un string ahí es a simple memoria, incluso puede que una mayúscula donde no haya yua o algo así
Douglas (07:07)
Sí, fíjate que vos mencionaste algo importante. Yo, por supuesto, no programo, o no es mi función principal, manejo Python. Para quienes no saben todavía, manejo Python y cada vez que trabajo con base de datos, aunque de nuevo no he seguido, pues uso un ORM para interactuar.
Y es que eso por si solo a nivel personal Juan, para mí es el beneficio que hace que los contras que tiene porque tiene sus contras, vos lo dijiste al principio y estoy seguro que no los vas a mencionar más adelante, pero ese beneficio hace que los contras que tiene sean superados en mi opinión en particular.
tener la estructura, el tipo de datos, no tengo que estarme preocupando por a la hora de hacer el insert que maneje el tipo de datos correcto, verdad. Obviamente siempre tengo que tener ciertos cuidados. Esto no va a ser una clase de cómo programar y usar ORMs y si así lo fuera, Juan sería quien dirigiría el tiempo y no yo. Pero a lo que voy es que me abstrae muchas preocupaciones y de cierta manera
Juan (08:05)
No,
Douglas (08:15)
hasta introduce cierto best practices por así decirlo, Juan, dependiendo del lenguaje y el ORM que estés usando, en cómo hacer inserts y modificaciones, a que si trabajara con el SQL directo yo soy responsable de esos queries y que el query sea óptimo y siempre si fuese algo muy profundo hacer, siempre lo mejor es hacer tu query, pienso yo, pero esto es para cosas ya grandes. respondiendo a tu pregunta, Juan, yo siento que ese beneficio
hace que los contras que vas a mencionar más adelante sean superados siempre y cuando sea un ORM que sea bien mantenido ya sea por la comunidad o por el vendor porque algunos vendors crean sus ORMs a veces, verdad, siempre y cuando sea bien mantenido hace que supere y en cuanto a la comunidad siempre hemos hablado este tema aquí Juan a veces cuando defendemos algo acá Paespae decimos no hay necesidad de que te vayas al otro lado
suelen ser opiniones muy sesgadas o cerradas porque yo puedo estar convencido para mí de que este beneficio que acaba de dar del ORM supera los contras que tiene.
Por ende, yo les aconsejo que consideren este beneficio mayor a los contras. Sin embargo, la decisión final es de cada quien y eso no lo va volver mejor o peor. Simplemente va a ser tu decisión y te vas a encargar de lidiar con las consecuencias que tenga y te vas a encargar de aprovechar los beneficios que obtuviste. Pero yo creo que por ese beneficio, yo a nivel personal siempre escojo un ORM.
Juan (09:56)
muy cierto, verdad es que ese es uno de los puntos muy fuertes que bien lo decías puede sobrellevar o superar a las de ventaja que podamos verle más adelante ya vamos a ir viendo un poco los puntos que tienen cada uno de ellos ya cada quien va a decidir si son buenos o malos antes de eso me gustaría pues mencionar cuál es si esta es la gran ventaja de los ORMs cuál podría ser la gran ventaja de escribir los queries
Y la verdad Douglas, desde mi punto de vista, hecho de escribir queries directamente en nuestro código nos da una... la mayor ventaja que yo veo es el control. El control de dos cosas. Número uno, poder escribir queries que son muy óptimos para lo que estamos haciendo en ese preciso momento. Sin tener que obtener columnas extras, sin tener que hacer joins extras, sin tener que hacer muchas cosas.
que muchas veces los ORMs pueden llegar a hacer. Y también el otro punto que me gusta a mí personalmente de tener los queries en el código, porque también se podría tener los queries en la base de datos con Store Procedures o funciones, la gran ventaja que veo es que al developer nos da una gran...
observabilidad de lo que tenemos en la base de datos podemos ver cuáles son los esquemas directamente en el código podemos ver cuáles son las columnas que tenemos y nos permite ver mucho mejor qué se está haciendo dependiendo del caso claramente que los store procedures y funciones pueden llegar a ser muy ventajosos o incluso mejor que tenerlo en el código
Pero para la gran mayoría de situaciones creo que tener los queries en nuestra base de código es una gran ventaja por el control que nos da a nosotros. Nos da esta facultad de poder tener la decisión de qué hacer y en qué momento hacerlo.
Douglas (12:00)
No sé si brevemente le explicamos a la gente que nos ve y nos escucha que es un query, perdón, una función y un store procedure para quienes no lo sepan. Yo lo entiendo perfectamente. En muchos casos prefiero store procedures porque son hechos por un...
VBA o alguien que realmente sabe y no por un developer que a veces pudiera sobrecargar la base de datos, ¿no? Sin embargo, ese es el motivo, no es que cualquiera me funcione mejor o peor a nivel personal. Pero vos desde la perspectiva de programador, no sé si lo explicás brevemente para como con mentalidad de programador también, ¿no? Me parece a mí que vale la pena por si alguien no entiende a que nos referimos con store procedures o funciones en la base de datos,
Juan (12:42)
Sí.
Douglas (12:50)
el query en el código, ya sea en tu aplicación que está llamando la base de datos.
Juan (12:59)
Si, muy buena aclaración la que estas haciendo Douglas, a veces se nos olvida y empezamos a hablar como si todo el mundo sabe lo que estamos hablando. Bueno, desde como ya lo dijiste perspectiva de developer, tanto los Store Procedures como las funciones, es código de SQL.
que número uno está guardado en el servidor o en la base de datos y se ejecuta directamente allí. no tenemos que... ¿Cuál es la diferencia? Con los queries que nosotros escribimos en el código, nuestro código envía esas sentencias a la base de datos. En cambio aquí no, aquí simplemente las invocamos porque ya están guardadas. ¿Cuál sería la diferencia entre los Store Procedures y las funciones?
Para ser sincero, nivel muy muy estricto no sabría listarlas, sin embargo con las funciones suelen ser pedazos de código de SQL que son normalmente muy cortas, te retornan una información o hacen algo y los Store Procedures te permiten hacer diferentes pasos o múltiples acciones dentro de la base de datos.
así que ambos tipos de instrucciones son SQL que queda guardado en la base de datos por eso mencionaba que normalmente son ejecutadas o escritas por un administrador de la base de datos por eso mismo porque nosotros no tenemos acceso hasta ese punto
Douglas (14:26)
Sí.
Exacto,
Juan (14:30)
Sin embargo, mi experiencia Douglas, como developer me ha tocado hacer muchos Store Procedures, muy pocas funciones, la verdad, a pesar de que hay un DBA que al final revisa todo. supongo que el DBA es el encargado de revisar que lo que estamos haciendo no vaya a romper lo que tenemos más allá. Y bueno, es eso mismo a lo que me refiero, que tenemos mucho control.
puede llegar a ser un arma de doble filo, poder hacer las queries nosotros como developers y también creo que por ese punto muchas personas deciden irse por la opción de los ORMs porque no tienen que invertir tiempo en aprender todas las sintaxis, las buenas prácticas de SQL en teoría los ORMs ya los hacen por ellos
pero bueno, habiendo mencionado muy brevemente que es cada uno de ellos vamos a dar algunos puntos Douglas, me gustaría hablar algunos puntos que creo yo que valen la pena hablar sobre este tema en específico. El primero es sobre la seguridad que tenemos al momento de ejecutar los queries.
la seguridad y prevención de inyección de SQL. La inyección de SQL ya la hemos mencionado en otros episodios pero es básicamente recibir código malicioso por parte de los usuarios que se guarda en la base de datos para luego al mismo tiempo que se guarda o se lee vamos a ejecutar otras instrucciones de SQL que nosotros no queríamos.
y bueno lo que tienen los ORM es que normalmente ya tienen muchas capas de protección ante esto así que es muy fácil pues pasarle cualquier cadena de texto porque podemos estar muy seguros o bastante seguros que no va pasar nada que la librería o la herramienta que estamos utilizando ya va a sanitizar así se le llama normalmente
vas a anotizar todos los parámetros para evitar todo esto. Sin embargo, si bien es cierto con los queries puros, por decirlo así entre comillas, tenemos que hacerlo nosotros. La realidad Douglas es que ya hoy en día las librerías para conectarnos a las bases de datos ya también tienen esto implementado.
Por ejemplo en Go, la librería estándar de Go tiene un paquete para bases de datos y nos permite pasar parámetros y estos parámetros son sanitizados también por la misma librería. Así que en este punto yo creo que están empatados Douglas porque ambos te permiten ⁓
pues resguardarte ante esta amenaza que existe en la actualidad. Yo antes pensaba Douglas que dentro de mucho tiempo decía yo, ya no va a existir este problema de la inyección de SQL, ya nadie se va a preocupar y pues no, la verdad es que es un problema que creo yo que nunca va a desaparecer, lamentablemente, siempre hay que pensarlo.
Douglas (17:39)
Sí, y esa ventaja igual no quiero deviar la plática si no se está ahí todavía, pero esa es una ventaja me parece muy buena. Sin embargo, si se descubre una vulnerabilidad que tiene un decoding injection en tu ISAS ORM, dependés del vendor que lo actualice para que luego lo puedas implementar.
porque ellos son los que manejan el código fuente. Mientras tanto, usualmente suele ser rápido, ¿no? Pero mientras tanto, si la vulnerabilidad es crítica, tienes que escoger entre deshabilitar esa función por mientras o tratar de poner capas intermedias para capturar y satisfizar antes. Mientras el vendor saca el ORM, mientras que si lo manejas, vos mismo, pues, te encargas de parchearlo rápidamente. Entonces, de nuevo, son cositas a considerar.
creyendo que los beneficios del ORM superan este tipo de ventajas porque igual tiene que tener tiempo alguien para ponerse a parchear el código aunque lo maneje vos mismo, algo tiene que hacerlo siempre. Pero en fin, son cosas a considerar como siempre y como todo tema en lo que tiene que ver con desarrollo y tecnología.
Juan (18:45)
Alguien lo tiene que hacer.
Exacto, exacto. Otro punto que me gustaría hablar sobre esta línea de lo que hay que hacer en los queries y todo esto es el hecho de las migraciones y observabilidad porque aquí creo yo que tiene un punto a favor las librerías o herramientas de ORM porque nos permiten o ya tienen VIRTUAL TEAM, o sea ya tienen escrito en su núcleo
la capacidad de ejecutar migraciones. ¿Qué es una migración? Es básicamente nosotros la facultad de poder escribir los cambios a la base de datos en nuestro código.
y eso se va a ejecutar por una herramienta que aplica esos cambios ya sea que agregamos una columna, la quitamos, cambiamos el tipo de datos, todo eso en vez de simplemente ir a la base de datos y hacer el cambio pues tenemos una lista de todos los cambios que se han hecho y eso nos permite tener una trazabilidad y ver todo lo que ha pasado pues bien, en el ORM al ser pues CodeFirst
pues nos permite tener esto de manera muy simple en la mayoría de los casos con los queries directos, el SQL puro la verdad es que no tenemos una opción como esta sin embargo también hay herramientas en este caso lo que sucede es que nos toca tener otra herramienta a la par que es la que se encarga de tener el control de las migraciones
hay varias herramientas hoy en día pero pues lo que se suele hacer o la estrategia es esa escribimos todas las migraciones nuevamente y ahora tenemos una herramienta extra que se encarga de aplicar esas migraciones así que creo que en ese punto Douglas aquí si los ORM tienen como que un punto a favor contra manejar los queries directamente en el código sin embargo
en cuanto a la observabilidad lo que pasa es que cuando tenemos ambas soluciones en los ORMs y los queries esto también deja logs en la base de datos los ORMs como ya dije por debajo utilizan sentencias de SQL así que con los queries como tenemos queries que están específicamente para una cosa
pues normalmente son dos que tres líneas de código o muy pocas líneas que se van a loggear en la base de datos. En cambio en los ORM es muy fácil que dejen cientos de logs porque están haciendo múltiples cosas al mismo tiempo. Así que ese es un punto que podría ser a favor o en contra dependiendo de cada quien.
el hecho de tener que revisar los logs de todo lo que está pasando y ver que con los ORM pues tienes que aprender a navegar estos logs que dejan. Es un poco de nicho ese punto pero pues vale la pena mencionarlo por si a alguien le toca revisar esto van a poder darse cuenta de esta situación.
Douglas (22:10)
Ya te dije en eso, Juan tiene,
no sé si, con respecto a la observabilidad, eso que decís, pudiera tener de repente su ventaja en, al menos lo que concierne a la parte de sistemas. No queremos, no necesitamos tanto log transaccional de cada cosa que se hizo, no siempre es así. Sin embargo, sobre todo en la parte de la aplicación que da la cara al cliente, querés tener los queries.
que se están ejecutando. ¿Crees que eso se guarde el query específico? Porque si tenés queries lentos, usualmente se usa un APM, un software de APM, para registrar todo este tipo de métricas y hacer los traces o la correlación desde los llamados del front-end, usuario, el query que se hizo, conexión al object cache, llamados al servidor y errores en el servidor y todo eso. Hace un trace y conecta un servicio con el otro.
Juan (22:51)
Exacto.
Douglas (23:09)
Y querés tener en realidad el query que se ejecutó. Porque si el problema es el query, es un query que está lento. Porque el query en sí como tal, o es muy grande, o es muy pesado, o está mal hecho, mucha concatenación, mucha base de datos temporal. Queremos identificarlo para corregirlo. Entonces, con un ORM, a veces si solo le das user.insert, porque es el objeto que te creó el ORM.
Juan (23:13)
Mm-hmm.
Douglas (23:39)
ya lo modificaste, ahora le das user.insert, puede que el query es diferente, pero entonces ya te hace ver dónde está el problema y tratar de encontrar cómo corregirlo. También el ORM te va a dar ciertas librerías que son un poco más fáciles de registrarlo y si lo haces manual, tenés que asegurarte de que dejes ese rastro.
para que se pueda loguear y que la observabilidad pueda identificar eso. Porque mencioné razones por las cuales eso es un problema, pero puede ser que el query esté bien óptimo, que los índices sean correctos y lo que ocupa es más recursos, ya sea en base de datos o en caché o en el servidor. Bueno, normalmente sería o caché o base de datos en un caso como este. Pero entonces, a lo que yo quiero ir es eso de dejar el registro, dejar el log.
del query específico que se corrió y cuánto tiempo tomó es indispensable. Usen ORM o usen SQL directo. En su código tienen que asegurarse de dejar ese registro para que su software de APM pueda hacer el trace, el rastro de toda la conexión y conectar una cosa con la otra y pueda hacer troubleshooting.
Juan (24:49)
Sí,
buen punto, porque a veces tenemos la idea de, ok, yo creo que lo que está pasando es esto, pero no tenés como probarlo. En cambio, al tener una línea de los logs y todo lo que está sucediendo, entonces podés llegar a una conclusión más fácil para tomar otras decisiones, como decías, aumentar los recursos.
Douglas (25:06)
Sí, fíjate.
Correcto, correcto. Y como comentario final y de experiencia práctica, cuando tenemos muchas veces en field donde yo trabajo, ya lo he mencionado, una de las fuertes es WordPress, cuando tenemos clientes que tienen problemas de rendimiento, una de las primeras preguntas que hacemos es, ¿tienen un software de APM? Ya sea Datadog, ya sea New Relic o lo que sea, Signos, lo que quieran utilizar. ¿Tienen un software de APM implementado? Si la respuesta es no.
Juan (25:28)
mmm
Douglas (25:35)
Comenzamos a ver otros logs, pero parte de los primeros pasos es implementemos el software del APM, pongámoslo a correr, vayamos viendo otros logs por mientras, pero el veredicto final se va a dar hasta que tengamos el APM ya implementado, porque eso nos va a poder, nos ayuda a encontrar dónde es normalmente, se está tardando, dónde está el cuello de botella y tal cual lo que te estoy diciendo, los queries que se están corriendo, ¿verdad? por experiencia propia,
nunca damos un veredicto primero si el APM no está instalado, de hecho nos toca dar un paso atrás, instalar el APM, dejarlo que corra unos días antes del veredicto, entonces, ¿quieren salvarse ese tiempo? Implemento un APM, asegúrense que sus conexiones a base de datos sean por SQL Direct o por ORM, estén logueando el query que está ejecutando y cuánto tiempo toma en completarse.
Juan (26:29)
son de esos problemitas que al inicio pues no lo vemos los developers no nos preocupamos por eso hasta que si es necesario hasta que falla bien, avanzamos un poquito más en esta plática algo que también suelo escuchar mucho Douglas en favor de los ORMs pero aquí yo sí personalmente considero que
Douglas (26:40)
hasta que falla.
Juan (26:59)
no es la gran ventaja, yo diría que no es una ventaja y es la portabilidad. Normalmente al ser los ORMs muy abiertos en cuanto a qué bases de datos nos podemos utilizar, a cuál nos conectamos, porque desde nuestra perspectiva podemos simplemente llamar al objeto users
y la propiedad email y realmente eso es independiente de si viene de MariaDB, viene de Postgres, SQLite, lo que sea. Eso ya se encarga el ORM de cómo va a ser ese query. Entonces por eso un punto muy fuerte siempre en los ORMs es el hecho de la abstracción muy alta en cuanto al motor de base de datos.
Sin embargo, desde mi punto de vista Douglas, yo creo que esta portabilidad no es una gran ventaja porque en la práctica yo muy pocas veces he visto que se vaya a reemplazar una base de datos. En lo que llevo trabajando en el medio, creo que lo he visto una o dos veces.
y creo que ya lo he mencionado antes, es que se reemplaza directamente simplemente lo que sucede es que empezamos a hacer otras funcionalidades y luego se migra la información lo estoy simplificando muy mucho pero realmente es algo que yo siempre estoy no digo en contra
pero ya llevado a la práctica creo que esa portabilidad pues nunca la logras ver o sacar el provecho que te venden siempre con los ORM así que si eso es la práctica, tener el query realmente optimizado para digamos SQL Server pues no importa porque muy difícilmente
la empresa va a cambiar de base de datos y entre más pasa el tiempo más difícil va a ser porque bueno migrar miles de usuarios es complicado es muy muy difícil así que ese es un punto que yo siempre digo dublas no me convence
Douglas (29:17)
Sí, y esa es una de las cosas también, que aunque de verdad pase en algunas empresas, pasa una sola vez, una sola vez. Y es tan grande el cambio que aunque uses un ORM o usés SQL Directo, te toca hacer cambios en código, muy probablemente, porque no es lo mismo, probablemente, la forma en que te actúas con información entre una base de datos y otra en algunos escenarios pequeños.
bases de datos SQL en su gran mayoría son lo mismo, Pero a lo que voy es de que si de verdad es una ventaja de esas cosas que sí.
si haces una portabilidad a otro engine de base de datos pasa una sola vez y punto. No es como la portabilidad de correr en cualquier sistema operativo, correr en ambientes de desarrollo, producción, preproducción o en diferentes nubes. sea, no es ese tipo de portabilidad. Entonces, yo estoy de acuerdo con vos. Es real lo que dicen sí al tener un ORM.
va a ser menos lo que vas a cambiar si te cambias de engine de base de datos. Sin embargo, ¿qué tan seguido va ocurrir? Suena una de esas ventajas que te da un vendedor cuando te ofrece un nuevo servicio. Será cierta, pero nunca la vas a utilizar. Entonces, estoy de acuerdo con vos ahí en ese sentido.
Juan (30:28)
Sí.
Sí.
que bueno, que bueno, no estoy solo entonces y bueno me gustaría hablar de un último punto para ir cerrando el episodio de hoy en cuanto a los puntos de comparación y bueno es el famoso problema N más 1 el problema N más 1 se refiere a que por una cantidad de queries
que tal vez esperábamos que se ejecutaran 2 o 3 instrucciones se va a ejecutar mínimo una más y a veces sucede que se ejecutan muchas más y voy a tratar de ilustrarlo un poco más simple digamos que yo quiero obtener la lista de usuarios y por cada usuario quiero también obtener la lista de amigos que tiene cada uno de ellos entonces con el ORM probablemente la sintaxis va a ser muy fácil porque
nos permite ir concatenando con dot notation y vamos obteniendo toda la información que queremos. embargo, que realmente está sucediendo, si no pensamos de antemano con esto, es que puede llegar a suceder que hacemos un select de cada uno de ellos por ID y luego en cada uno de estos select hacemos otro nuevo select o múltiples selects.
Entonces eso puede llegar a mucha carga en la base de datos. lo personal, ese siempre ha sido uno de los puntos que para mí son los más, qué se yo, los más peligrosos de utilizar los ORMs. Aunque obviamente he de admitir que en la actualidad los ORMs han sido mucho más optimizados de lo que eran hace 5 o 10 años atrás, ¿no? Pero aún así...
siempre considero que no es comparable la optimización que puede tener un query donde yo escribo un inner join, un left join en el mismo query a tener que utilizar los ORMs, múltiples joins y por cada join un subquery y bueno hace muchas cosas que al final del día es una caja negra para nosotros no sabemos qué lo que está sucediendo realmente
y pues cuando el query es muy complejo puede tener un impacto muy grande en el rendimiento de todo, de toda la aplicación porque tal vez no se cae pero se ralentiza la base de datos, se ralentiza los procesos, se empiezan a llenar las colas y bueno puede ser un evento, una bola de nieve en esto. Ahora aquí sí voy a admitir que puede ser debatible.
es culpa del ORM o es culpa del developer que no pensó en esto al momento de hacer este query o incluso al momento de diseñar la base de datos porque a veces si tenemos estas cosas si ya sabemos que vamos trabajar con ORM podríamos en ciertas ocasiones incluso anticiparnos y diseñar las tablas y las columnas de diferente manera para poder pues no tener que ir y hacer múltiples subqueries para obtener un valor
Pero bueno, ese es uno de los puntos más grandes para mi Douglas que siempre me ha hecho pues retirarme un poco de los ORMs. Debo admitir que no soy un gran fanático aunque bueno ya lo mencioné, hoy en día creo que los ORMs son mucho mejores de lo que eran hace mucho tiempo atrás. Entonces tampoco creo que sean un gran mal en el stack de cada quien. Muy bien.
Douglas (34:30)
Sí, va a depender
por escenario, ⁓
Juan (34:32)
va
depender de escenario, va a depender de los queries y aquí a lo que me lleva Douglas es que entonces qué es lo mejor utilizar ORM o utilizar SQL desde mi punto de vista aquí hay varias opciones si utilizan ORM mi consejo sería identificar los queries más complejos los queries que requieran un rendimiento mayor
y esos queries probablemente, o ya sea abstraerlos y ponerlos en un Store Procedure.
o literalmente tener los queries en el código de nuestro sistema. Los ORMs, hasta donde yo recuerdo, la última vez que los probé, también te permiten ejecutar queries directamente, si así los necesitas. Entonces, una mezcla o una combinación de ambos creo que al final del día es la mejor opción porque tenés las ventajas de ambos mundos en un solo punto. No tenés que cambiar ni uno ni el otro. Porque...
Debo reconocer que hacer queries directamente en el código puede ser muy tedioso y puede ser muy complejo si no tienes la experiencia. bueno, independientemente de Douglas, si utilizan o no ORMs, aprendan los fundamentos de SQL.
Douglas (35:55)
¿Muy de acuerdo? Sí.
Juan (35:55)
eso no
lo dejen por fuera si estamos utilizando un ORM eso no quita el hecho de que estamos interactuando con bases de datos de SQL así que necesitamos esos fundamentos para saber cuál es la mejor opción un left join o un right join o un inner join un outer join hay muchos joins entonces hay que aprender eso no se dejen llevar por el hecho de que no necesitan saber SQL si lo necesitan
Douglas (36:26)
muy de acuerdo con vos, Y yo lo que agregaría y a lo que está diciendo es que me gusta el consejo que está dando, ¿no? No lo había considerado de esa manera, de que si usan ORM, los queries más complejos y más cargados los manejen de manera aparte, ya sea en código, en soft procedures. Y solamente quiero mencionar, pues eso aplica si tu aplicación es medianamente compleja o muy compleja. Puede ser que no lo necesitan.
necesites en lo absoluto, no es que estás mandando a la gente a vayan a buscar cuáles queries ponen y cuáles no, si tienen queries que sean más complicados, los hacen manual de lo contrario, si la aplicación es simple o no tiene queries tan complejos, todo lo va a hacer el ORM.
Juan (37:16)
Sí, sí, definitivamente puede ser que no lo necesiten. Aunque eso puede ser un tema para otro episodio Douglas, el cómo hoy en día dejamos la optimización para después y pareciera que hace muchos años atrás se pensaba con la optimización desde el inicio. Eso es un tema que me parece muy interesante de platicar.
Douglas (37:39)
problema de la abstracción, antes no era abstracto,
me tocaba pensar en el rendimiento ahora es abstracto, no me preocupo por ello.
Juan (37:46)
Buen
punto, buen punto. No lo había pensado así. Antes no teníamos eso. Me gustaría cerrar Douglas con una última opción que veo mucho más que se está levantando hoy en día. Que muchas personas están hablando sobre ella.
Debo admitir que yo personalmente no lo he probado, aunque sí lo he estado estudiando un poco por encima, un poco la teoría y las herramientas que hay. Y es el hecho de tener lo que se llaman los Query Builders. ¿Cómo funciona esto? Lo que hacemos es que creamos los queries, los SQL queries, los statements, y pues con una serie de sintaxis de comentarios donde le ponemos el nombre y los parámetros.
ejecutamos una herramienta y esta herramienta ahora genera un código optimizado específicamente para ese query que luego nosotros podemos utilizar entonces es como si tuviésemos un ORM hecho a la medida algo así es como yo lo veo y bueno por ejemplo en Go que es el que se me viene a la mente existe uno aunque creo que también puede ser utilizado con otros lenguajes que se llama SQLC y es muy muy interesante
de nuevo lo he estado nada más viendo pero es interesante cómo te permite crear queries, permite crear el esquema de la base de datos con diferentes configuraciones también te permite validar que si ahora cambiaste un query o si modificaste una tabla te permite validar si tus queries todavía funcionan o cuáles queries van a explotar con el nuevo cambio
muy muy interesante aunque pues si te cambia todo lo que es el flujo de trabajo porque ahora tienes que estar ejecutando herramientas por aparte aunque la verdad es que hoy en día Douglas el ambiente de desarrollos también pues se trata de eso estar ejecutando múltiples herramientas en paralelo y que están generando código están generando muchas cosas es una gran alternativa para las personas que
no están muy de acuerdo con los ORMs pero pues no quieren o quieren tener la ventaja de poder ver los objetos, tener el tipado de las propiedades de las columnas directamente en el código, esto es una gran opción. Como dije la que se me viene a la mente ahorita es SQLC pero sé que hay para otros lenguajes y hay otras herramientas que hay por ahí que vale la pena pues revisarlas creo yo.
No sé si alguna vez habías escuchado sobre eso Douglas, creo que es algo nuevo. No sé qué tan nuevo, la verdad.
Douglas (40:26)
No, sí lo he escuchado, fíjate, lo he escuchado recientemente, por ahí he platicado con un desarrollador que lo ha usado. Lo que ocurre es que en mi caso, al final administrando la parte de servidores y sistemas, no me impacta mientras los queries sean óptimos, mientras no genere carga además en la base de datos, ¿no? Porque pues no requiere esto.
configuraciones diferentes a nivel de base de datos, si lo queremos llamar de esa manera o a nivel incluso en la conexión en sí misma como tal, ¿no? Porque según entiendo siempre ocupas una manera de conectarte desde tu aplicación hacia la base de datos y eso pues de manera esencial no cambia, ¿no? Voy a mandar una conexión segura, voy a generar un usuario en password o las diferentes maneras según la base de datos de conectarse hacia ella y entonces es por eso que no...
Juan (40:54)
Buen punto.
Douglas (41:20)
tengo como una opinión más grande o más significativa al respecto. Sin embargo, si lo he escuchado, ya tiene sus cuantos diítas por ahí en la industria, al menos que llegó a mis oídos, ¿verdad? Y como vos dijiste, si alguien quiere tener los queries de manera directa, pero no dedicarle tanto tiempo a aprender todos los micos y pericos, como decimos por acá, de SQL, es una opción. Igual, pues pueden utilizar la inteligencia.
artificial si quieren construir queries porque con la inteligencia artificial pueden decirle el problema que tienen, la estructura de base de datos, qué tipo de query y el query final luego le pueden pedir que se los explique. Explícame por qué usted es un left join y no un verdad...
Juan (42:06)
Es cierto.
Douglas (42:06)
inner
join o algo por el estilo y lo van a entender de una manera más digerida. De nuevo esto es un comentario desde la poca experiencia con los query builders, sin embargo recuerden al final el resultado con query builder o no, la conexión desde la aplicación hacia la base de datos eso no cambia.
Juan (42:28)
sí, eso se mantiene, eso los fundamentos de SQL se tienen que mantener y lo que mencionabas es al inicio me parece que es un buen mensaje no hay que, bueno lo voy a como parafrasear mencionabas que no hay que estar cerrados y defender solamente una postura hay múltiples opciones de cómo solucionar diferentes problemitas que se notan en el mundo de programación así que bueno
aquí están los puntos que yo encontré que sean más relevantes en cuanto a estas dos soluciones que hay hoy en día, estas dos alternativas ya quedaría de cada quien decidir si pues decir qué opción va a utilizar en su próximo proyecto y bueno ojalá que les haya sido de mucha ayuda en los temas si creen que dejamos algo por fuera déjenlo los comentarios o si quieren que toquemos algún otro punto un poco más a fondo dejen en los comentarios para
puede ser en un futuro tenerlo en cuenta. Muchísimas gracias a todos los que nos han acompañado hasta este punto y bueno nos vemos a la próxima. Bye.