ORM vs SQL ¿Cuándo usar cada uno? 🤔 

¿Sueles utilizar ORM? ¿Cuando prefieres utilizarlo y cuándo no?

SQL es hermoso, tanto para proyectos grandes como pequeños; tienes todo el control de las consultas y un gran rendimiento en su ejecución. Los ORM puede darte desagradables sorpresas si no los utilizas correctamente en bases que escalen demasiado.

Justo hoy estaba empezando un proyecto pequeño en mi empresa y estaba investigando sobre si usar o no ORM 🤗

Increíble, hace unas horas justo estaba buscando información al respecto

Gracias por compartir sus experiencias y conocimiento :) esta muy cool su contenido

Buen fichaje este Dani ;-)

Pase dos años haciendo casi exclusivamente solo SQL, aprendí un montón de cosas pero... realmente prefiero usar un ORM siempre que este disponible, sobre todo cuando hay varias personas trabajando sobre el mismo código y las tablas tienen relaciones complejas, ademas tampoco se pierde taaaanto rendimiento..

Excelente video!.

Yo llevó desconectado del ecosistema PHP unos años, pero creo recordar que PDO si evita la inyección SQL. De echo es el sustituto de la librería MySQLi que si tiene problemas de inyección SQL. ¿No es así? En cualquier caso muy interesante el video. 😉

8:16 A parte del argumento que da Dani sobre los condicionales en las consultas, otra ventaja muy importante y que destacaría es que usando el queryBuilder nos podemos abstraer de la tecnología concreta de base de datos ya que DBAL sería el encargado de montar la query para ya sea MariaDB, PostgreSQL... etc. Por otro lado, si usamos el approach de SQL en raw, nos estamos acomplando a esa tecnología en concreto para la cual hemos escrito la consulta (sí es cierto que para consultas sencillas de SQL no importaría ya que serían compatibles). ¡👍🏻 Muy buen vídeo 👍🏻!

ORM para consultas simples y SQL para consultas pesadas c:

Mola que os hayáis puesto de acuerdo en el colORM de la camiseta 😅

21:53 excelente! 🥳 Saludos...

Que opinan de probar métodos que consultan la base de datos? Por ejemplo con DBUnit o similar

HOLA, como Hacemos un proyecto laravel symfony que tiene patrones de diseño y mucha carga de objetos escalable sin quedarse pobre por los recursos en memoria y procesador que se consume al tener el Monolito

Un curso de diseño u gestión de base de datos (de las más conocidas y open source, como MySQL, o Postgres).

Porfa me pueden aclarar a que se refieren con 'proyecciones' .

se pueden tener las consultas en un procedimiento almacenado y solo llamarlo y enviarle los parámetros, es correcto ?

Honestamente, los ORM son una caja negra con un performance muy pero muy malo , mejor realizar consultas optimizadas desde el principio aunque demores un poco porque el dolor de cabeza de migrar despues va hacer Grande. claro esta cada quien saque sus conclusiones con sus experiencias.

hexagonal con ORM y consultas custom, la combinacion y usar cada cosa para lo que esta diseniada es lo idea

La seguridad tiene como precio el rendimiento

pero no entiendo, ellos hacen una consulta a un endpoint y ese enpoint les responde algo ¿y ese "algo" ya se fué a la base de datos? No entendí el paso de mostrarme el endpoint a ir al código, mas o menos 4:30 del video

22:45 bien dicho 👍

Y MyBatis de java donde se englobaría?

Se podría tratar un xml,json como fuente de datos de una tabla. Hay algun driver sql?

Que es eso del profiler? Dónde puedo leer sobre la herramienta?

donde haya una freequery con redis que se quite cualquier orm y más si tienes que hacer reporting

Que pensáis de flutter

Otro peligros de los ORM. Solo debería haber una aplicación leyendo de una tabla determinada? Si hay una app que lee y otra escribe como queda esa cache?

Yo en lo personal me quedo con lo tradicional, sin ORM y PDO, usando SQL de forma programáticamente, así aprendo de cosas nuevas que puedan surgir en SQL y tener el control total de lo que hago.

En lo personal me gusta mas sql, utitlizar ORM siempre me da bugs en algo xD

Spoiler alert. Ya no se usan Yaml. jejejejej van a tener que rehacer o más bien, deberán hacer una pequeña actualización. Hablando de ORM, sé que no lo es, qué opinan de usar graphql como ORM ? Yo para evitarme estar creando consultas SQL en el medio de mi modelo (porque uso MVC) me hice un par de métodos que hicieran eso, usando como conector y ejecutor de dichas consultas a PDO, qué opinion me dan de eso. Para simplificarles, para pedir algo o agregar algo, haces una arreglo con cierta estructura y se lo pasas a una función y esta usando otra función pero ésta vez con las herramientas de PDO se conecta a la base y devuelven el resultado en un arreglo asociado listo para consumir.

Spoiler: Si el ORM tiene lo que te hace falta, siempre que puedas.

Por cierto, lo de las camisas casi iguales Jajajajajajajajaja

Si lo uso, siempre que se pueda y no me complica lo uso, RE

Eloquent de Laravel no necesita mapear la bd

ORM + QueryDSL la salud

La explicación seria mas hermosa si hubiese empezado con Java o Javascript :v

subtitle please

Si el objetivo era darme tips sobre cuando usar uno y cuando otro para empezar un desarrollo, su video no me aporto casi nada. Los tips que dieron es cuando ya está hecho y eso no me sirve de mucho. En cambio yo me enfocaría si la base es heredada y tiene claves compuestas (pésima práctica) no usaría un orm, y si la base está bien hecha (es decir, claves enteras únicas) si usaría un orm. La cuestión es poder decidir antes del desarrollo y no después, ya que los temas de rendimiento se ven después, cuando la aplicación está en producción y se conoce el volumen de uso, y los tips que me han dado es para cuando ya está hecho. Además cada orm tiene la opción de ejecutar sql directo cuando el rendimiento de una operación con orm no es óptima. Me gustarían tips para decidir desde el análisis y diseño, y no tips de rendimiento para cuando ya está implementado.

El ORM de Laravel tambien es bueno.

¿Y Entity Framework no os merece un comentario? :D