Algunas notas que estáis mencionado: - Se puede rellenar una tabla con un CSV directamente desde consola. Efectivamente, pero no siempre es tan fácil, a veces tienes que convertir los datos a otro formato (rediseño de la BD) o sacar los datos de otra API o de otro sito. El tip es agrupar los inserts, no tanto el CSV, el CSV era solo un ejemplo. - En compiladores más antiguos no se puede cambiar un if dentro de otro por un and porque no garantizan que la evaluación del and sea de izquierda a derecha. En estos casos lo que se puede hacer es poner uno después de otro, si es que vas a retornar nulo u otro valor. - No es el lenguaje como tal el que tiene un "estándar" para la nomenclatura de variables/funciones/clases. Existen varios estándares para cada lenguaje. A lo o que me refería es a usar el estándar mayoritario, que usa la mayoría de gente.
Si, en la práctica antes de cada registro se requieren validaciones que no dependen del tipo de dato si no del modelo de negocio. A medida que estas se cumplan se pueden ir agregando al query.
Para el primer tip, puedes mejorarlo aún más usando el LOAD DATA INFILE de mySQL, que lo que hace es básicamente leer directamente el fichero y lo vuelca a base de datos, ya te imaginas lo rápido que puede llegar a ser
Eso mismo iba a decir, sin embargo el uso del script es muy valido cuando se necesita procesamiento de la linea, escapar, componer, agregar, remover, etc
El tema con eso es que necesitas acceso al propio servidor, porque el INFILE es un archivo en el disco del servidor. Como estés en una base de datos administrada por otros (como puede ser Amazon RDS), ya no puedes hacer eso. Y aún si tienes acceso, tienes que saber en qué directorio colocar el archivo, ya que MySQL no puede leer de cualquier lugar del sistema.
Una cosa, en el primer tip es tan extremadamente lento porque haces una query por insert, pero lo habitual (cuando no los importas sino que rellenas desde una API o algo así) es hacer INSERT INTO [... ]VALUES([...]),([...]),([...])... En PostgreSQL al menos, los datos se almacenan paginados de 8KB en 8KB. Si no recuerdo mal, usan LSMTrees para optimizar la inserción. Al pasar todos los VALUES en una sola query, es capaz de analizar cómo guardar mejor la información y es mucho más rápido (si mandas los values de uno en uno, no sabe cuál es el siguiente y no puede optimizar el espacio para el anterior). El comentario va con la intención de explicar el motivo, que no es solo el interrupt del sistema operativo. Muchos ORM aprovechan esto y te obligan a hacer el #commit() o algo así para generar una sola query. Espero que te resulte de utilidad (quizá ya lo sabías), y que leas esto :)
En cuanto a la nomenclatura..... no depende del lenguaje, depende de los estándares de naming. Por ejemplo en python se suele usar PEP8, pero hay otros. Y en C ocurre igual. Hay varios estándares. Cada uno usa el que quiere. De hecho suele ser habitual indicárselo a linter para que te advierta cuando lo incumples. Pero no es cosa propia del lenguaje en la mayoría de los casos. De hecho si así fuera, estaría implementado en el lexer.
Acerca del tip 4, tambien se puede aplicar lo mismo a la hora de llamar a una función, es mucho mejor que esta se encuentre en un diccionario o un mapa que hacer un montón de condiciones para cada caso, solo hay que investigar un poco el lenguaje con el cual se esta trabajando para encontrar la manera de hacerlo, en caso de ser posible te ahorras varias lineas de codigo y ganas un codigo mas limpio y legible.
Al ver que duraba 27 minutos pensé en que se me iba a hacer eterno, pero se pasó de volada, haces muy interesantes tus videos incluso para explicar cosas técnicas bro (:
En Oracle, si yo quiero hacer eso, tengo varias alternativas, 1) generar un archivo CTL para levantarlo con un loader, 2) crear una tabla externa con el archivo y usarlo como parte de la base de datos, 3) correr los inserts dentro del servidor desde una interfaz sql abierta directamente en la base, 4) crear un proceso de base que levante todo eso en memoria y luego lo inserte utilizando una sentencia forall. Todas esas alternativas eliminan el tráfico de red que generan los lenguajes no nativos a la base de datos, o lo minimizan, como él caso de la 4ta alternativa. Esa sentencia tiene como propiedad el aprovechar los paquetes del tráfico de red en toda su capacidad.
Bro, y si tienes multibles tablas como 5 que estan relacionadas con la informacion que vas a procesar, cual seria la solucion? crear un store procedure para insertar las 5 a la vez?
@@secundariab.2741 primero tenes que determinar el orden en el que vas a insertar, si tenes múltiples tablas con datos relacionados, por lo general, unas son transaccionales y otras son tablas base que alimentan a las primeras. Para que los inserts no fallen, tenes que empezar por las tablas base, y luego ir a insertar en las transaccionales. Una vez que determinaste el orden en que deben ser insertados los registros, elegís alguno de los métodos, dependiendo de cómo estes trabajando los datos.
Cada día más crack 💥💥, sería bueno más videos de estos con ejemplos con código como buenas prácticas, principios solid, refactoring o patrones. (me gustó mucho que cada topic tenía su ejemplo práctico)
Muchas gracias por los tips Antonio, yo recientemente he conseguido mi primer trabajo como desarrollador y estos tips me van a servir bastante y desde luego que los aplicaré, espero que de vez en cuando subas videos de este estilo.
24:02 No solo sirve para que te aparezca en el IDE, el jsdoc en js sirve como validador de tipos tal y como hace typescript si añades un checkJS: true al tsconfig, además podrás ejecutar el tsc solo como validador en la línea de comandos, sin tener que transpilar a JS. Ese es el valor fundamental del jsdoc, tener validación de tipos sin necesidad de typescript, ya que al final es solo sugar.
Antes de pasar a mi comentario, felicitarte por este enorme esfuerzo que haces. Está súper. Con respecto al último tip sobre nomenclaturas, es cierto, pero... En el "corpus" de todos los lenguajes de programación existen elementos comunes, esos son: * variables * constantes * funciones * clases * keywords etc... Lo bueno sería poder diferenciar estos elementos, y en el caso de variables y funciones, ambas escritas en snake_case, no se pueden distinguir cuál es cuál. Por ello, estaría bueno que, para nombres de variables y propiedades de una clase usemos siempre snake_case en minúsculas, y para nombres de funciones usemos camelCase (esto también aplica para métodos). En general lo usaríamos asi: * variables o propiedades (snake_case) * constantes (MAYÚSCULAS) * funciones y métodos (camelCase) * clases (UpperCamelCase) * parámetros (snake_case) ya que los parámetros son variables En mi mejor entender, con esta forma sí ya podemos distinguir a los elementos. Un fuerte abrazo y más videos así.
Hace años podría ser interesante hacer eso, pero hoy en día como tienes coloreado de sintaxis sabes cuál es cuál. Yo al menos me baso más en el color que el formato del nombre para saber si es función/clase/variable, etc
Me has animado a darle una revisada a javascript y node, yo es que no soy desarrollador, pero si cargo mi arsenal en pendrives para ahorrarme varias horas manuales en la oficina. Habrás encontrado alguna herramienta que se asemeje a pillow de python en js? Felicidades por como ha crecido el canal y sobre todo el contenido!
Por temas de atomicidad, esta manera de encararlo es mas rapido pero en caso de haber un error en el proceso se ROLLBACKEA toda la transaccion, al hacerlo de manera poco optima estarias asegurando la atomicidad de todos los datos (solamente no se insertaria el o los valores erroneos, no se descartarian todos los datos)
he programado por dos años (por hobby) en proyectos propios... pero todos los consejos me sirvieron mucho!.... por ahí no tanto el de CSV a SQL, pero si piensas en la teoría de lo que has dicho igual se aplica a muchas cosas más (simplificar el código para que todo entre, de ser posible, en una sola línea de código)... espero que saques nuevos videos así!
llevo mas de 2 meses tratando de aprender progrmacion y siento que no aprendo nada con este video me has echo entender varias cosas y seguire intentado aprender js mas a profundo que es lo que me interese ay html y css
Un Linter vendría bien para un estándar de código y si no lo hay pues sugerirlo en tu trabajo, os ahorrares muchas discusiones de punto y coma, comillas dobles o simples y esos dilemas os lo aseguro 👍
Discúlpame si me equivoco, pero en el primer ejemplo no seria mejor manejarlo dentro de una transacción, porque el tema de conexiones a la DB se puede mitigar configurando un pool de conexiones. No es lo mismo realizar miles de registros uno por uno que hacer miles de registros dentro de una transacción usando únicamente un solo commit.
Hola Antonio, como siempre buenos videos, sólo un alcance; para hacer un insert de un csv más y más pro, puedes usar el load data de mysql, con php se puede y mucho más rápido y eficiente, yo lo ocupo para cargar archivos de miles de registros cada hora y la base ninse inmuta... eso no más, gracias por los videos
25:20, he trabajado en proyectos medio grandes de Python y eso se lo pasan por el forro. En este ultimo discrepo bastante, para mí no harás el "ridiculo" solo tienes que adaptarte al proyecto y con las personas con las que estés trabajando, ya que hay bastante mierdisenior que obligan a los juniors a trabajar con la nomenclatura que ellos digan xd
Si está hecho está hecho, no vas a cambiar todas las variables de un code base gigante solo para seguir un estándar. Si empiezas un proyecto nuevo en 2022 y pones camel case en Python pues hombre, será porque quieres porque otra razón no hay jaja. Pero yo he visto de todo gente que mezcla las dos cosas en el mismo proyecto por ejemplo.
Me gusta como en el min. 15:30 ya te anticipas a los comentarios y preguntas, y de una vez muestras la extensión jajajaja, se me hizo gracioso. Pero si, ya lo instale igual 😆
Muy buen video, otra cosa que veo hacer a mucha gente, incluso con experiencia, es poner condicionales ante boleanos en vez de devolver la expresion boleana directamente. Un saludo!
Vamoss por mas... falta esto en youtube.. te sigo crack..
Год назад
una mejor manera de realizar inserciones grandes a la base desde un orgien como un csv o un txt es realizar un load data infile, es casi instantanea la insercion de tus registros.
Claro eso es un guard clause, se usa en los early return pero no se refiere a exactamente lo mismo. Los guards son los ifs que vas poniendo para cubrir edge cases, early return es simplemente el hecho de retornar pronto si no puedes seguir. Creo que no hay un término exacto, yo lo puse en Google y salía retorno anticipado jajaja
Cuidado con quitar los if dentro de if. Hay lenguajes que no garantizan que se evaluen de izquierda a derecha como c++ hasta hace un par de estándares, y como la expresión de la derecha únicamente se pueda evaluar si la primera es verdadera vas a tener buenos errores. De hecho me pasó en una práctica de implementar protocolos de nivel de enlace en c++ que no le funcionaba a la profesora porque usaba una version de gcc anterior y en una parte que comprobaba si un puntero no es null y luego consultaba un valor lo hacía al revés dando un index out of bounds.
Sí en esos casos te la puede liar. Si tienes que retornar se puede poner en ifs distintos uno después de otro, no hace falta que este uno "dentro" de otro.
No es que múltiples inserts sean más lentos, es porque para cada insert se abre y cierra transacción. Si abres una transacción y sólo la cierras después de enviar los 100.000 inserts, es incluso más rápido que la solución que comentas.
un if dentro de un if hace exactamente los mismo que un and en el compilador y en el peor de los casos junto a la indentacion se lee mejor el codigo y el rendimiento es exactamente igual
Es verdad, pero el tip creo que podría aplicarse si algún usuario de una aplicación necesita cargar un archivo con información. No quieres que tenga acceso directo a la db y por lo tanto podrías crear esa funcionalidad
Algunas notas que estáis mencionado:
- Se puede rellenar una tabla con un CSV directamente desde consola. Efectivamente, pero no siempre es tan fácil, a veces tienes que convertir los datos a otro formato (rediseño de la BD) o sacar los datos de otra API o de otro sito. El tip es agrupar los inserts, no tanto el CSV, el CSV era solo un ejemplo.
- En compiladores más antiguos no se puede cambiar un if dentro de otro por un and porque no garantizan que la evaluación del and sea de izquierda a derecha. En estos casos lo que se puede hacer es poner uno después de otro, si es que vas a retornar nulo u otro valor.
- No es el lenguaje como tal el que tiene un "estándar" para la nomenclatura de variables/funciones/clases. Existen varios estándares para cada lenguaje. A lo o que me refería es a usar el estándar mayoritario, que usa la mayoría de gente.
Cual es tu lenguaje favorito
Buena aclaración.
@@no-name1.612 khee
Si, en la práctica antes de cada registro se requieren validaciones que no dependen del tipo de dato si no del modelo de negocio. A medida que estas se cumplan se pueden ir agregando al query.
the Art of postgresql... te enseña a no ser tan pendejo....
Me molarian más videos de este estilo
Para el primer tip, puedes mejorarlo aún más usando el LOAD DATA INFILE de mySQL, que lo que hace es básicamente leer directamente el fichero y lo vuelca a base de datos, ya te imaginas lo rápido que puede llegar a ser
Eso mismo iba a decir, sin embargo el uso del script es muy valido cuando se necesita procesamiento de la linea, escapar, componer, agregar, remover, etc
El tema con eso es que necesitas acceso al propio servidor, porque el INFILE es un archivo en el disco del servidor. Como estés en una base de datos administrada por otros (como puede ser Amazon RDS), ya no puedes hacer eso. Y aún si tienes acceso, tienes que saber en qué directorio colocar el archivo, ya que MySQL no puede leer de cualquier lugar del sistema.
Una cosa, en el primer tip es tan extremadamente lento porque haces una query por insert, pero lo habitual (cuando no los importas sino que rellenas desde una API o algo así) es hacer INSERT INTO [... ]VALUES([...]),([...]),([...])... En PostgreSQL al menos, los datos se almacenan paginados de 8KB en 8KB. Si no recuerdo mal, usan LSMTrees para optimizar la inserción. Al pasar todos los VALUES en una sola query, es capaz de analizar cómo guardar mejor la información y es mucho más rápido (si mandas los values de uno en uno, no sabe cuál es el siguiente y no puede optimizar el espacio para el anterior).
El comentario va con la intención de explicar el motivo, que no es solo el interrupt del sistema operativo.
Muchos ORM aprovechan esto y te obligan a hacer el #commit() o algo así para generar una sola query. Espero que te resulte de utilidad (quizá ya lo sabías), y que leas esto :)
Gracias hermano, así me queda más claro.
Crea mas videos asi... nos ayudan mucho a mejorar el rendimiento de nuestros proyectos
En cuanto a la nomenclatura..... no depende del lenguaje, depende de los estándares de naming. Por ejemplo en python se suele usar PEP8, pero hay otros. Y en C ocurre igual. Hay varios estándares. Cada uno usa el que quiere. De hecho suele ser habitual indicárselo a linter para que te advierta cuando lo incumples. Pero no es cosa propia del lenguaje en la mayoría de los casos. De hecho si así fuera, estaría implementado en el lexer.
2 videos en menos de una semana gracias por todo antonio, te queremos. con mucho amor tu comunidad.
Acerca del tip 4, tambien se puede aplicar lo mismo a la hora de llamar a una función, es mucho mejor que esta se encuentre en un diccionario o un mapa que hacer un montón de condiciones para cada caso, solo hay que investigar un poco el lenguaje con el cual se esta trabajando para encontrar la manera de hacerlo, en caso de ser posible te ahorras varias lineas de codigo y ganas un codigo mas limpio y legible.
Al ver que duraba 27 minutos pensé en que se me iba a hacer eterno, pero se pasó de volada, haces muy interesantes tus videos incluso para explicar cosas técnicas bro (:
La verdadera razón del tiempo que toma el insert, es que en cada uno se ejecuta de forma implicita un begin transaction con su respectivo commit
... además del tiempo de validación de sintaxis por parte del motor de BD para cada instrucción recibida
En Oracle, si yo quiero hacer eso, tengo varias alternativas, 1) generar un archivo CTL para levantarlo con un loader, 2) crear una tabla externa con el archivo y usarlo como parte de la base de datos, 3) correr los inserts dentro del servidor desde una interfaz sql abierta directamente en la base, 4) crear un proceso de base que levante todo eso en memoria y luego lo inserte utilizando una sentencia forall. Todas esas alternativas eliminan el tráfico de red que generan los lenguajes no nativos a la base de datos, o lo minimizan, como él caso de la 4ta alternativa. Esa sentencia tiene como propiedad el aprovechar los paquetes del tráfico de red en toda su capacidad.
Bro, y si tienes multibles tablas como 5 que estan relacionadas con la informacion que vas a procesar, cual seria la solucion? crear un store procedure para insertar las 5 a la vez?
@@secundariab.2741 primero tenes que determinar el orden en el que vas a insertar, si tenes múltiples tablas con datos relacionados, por lo general, unas son transaccionales y otras son tablas base que alimentan a las primeras. Para que los inserts no fallen, tenes que empezar por las tablas base, y luego ir a insertar en las transaccionales. Una vez que determinaste el orden en que deben ser insertados los registros, elegís alguno de los métodos, dependiendo de cómo estes trabajando los datos.
Me gustan estos videos que te ayudan a mejorar la refactorización y el estilo del código.
Cada día más crack 💥💥, sería bueno más videos de estos con ejemplos con código como buenas prácticas, principios solid, refactoring o patrones. (me gustó mucho que cada topic tenía su ejemplo práctico)
Muchas gracias por los tips Antonio, yo recientemente he conseguido mi primer trabajo como desarrollador y estos tips me van a servir bastante y desde luego que los aplicaré, espero que de vez en cuando subas videos de este estilo.
Muchas Gracias, justamente empezaré un proyecto de la Uni, aplicaré lo que dijiste :3
Me gustan este tipo de videos jajaja
24:02 No solo sirve para que te aparezca en el IDE, el jsdoc en js sirve como validador de tipos tal y como hace typescript si añades un checkJS: true al tsconfig, además podrás ejecutar el tsc solo como validador en la línea de comandos, sin tener que transpilar a JS. Ese es el valor fundamental del jsdoc, tener validación de tipos sin necesidad de typescript, ya que al final es solo sugar.
Antes de pasar a mi comentario, felicitarte por este enorme esfuerzo que haces. Está súper.
Con respecto al último tip sobre nomenclaturas, es cierto, pero...
En el "corpus" de todos los lenguajes de programación existen elementos comunes, esos son:
* variables
* constantes
* funciones
* clases
* keywords
etc...
Lo bueno sería poder diferenciar estos elementos, y en el caso de variables y funciones, ambas escritas en snake_case, no se pueden distinguir cuál es cuál. Por ello, estaría bueno que, para nombres de variables y propiedades de una clase usemos siempre snake_case en minúsculas, y para nombres de funciones usemos camelCase (esto también aplica para métodos).
En general lo usaríamos asi:
* variables o propiedades (snake_case)
* constantes (MAYÚSCULAS)
* funciones y métodos (camelCase)
* clases (UpperCamelCase)
* parámetros (snake_case) ya que los parámetros son variables
En mi mejor entender, con esta forma sí ya podemos distinguir a los elementos.
Un fuerte abrazo y más videos así.
Hace años podría ser interesante hacer eso, pero hoy en día como tienes coloreado de sintaxis sabes cuál es cuál. Yo al menos me baso más en el color que el formato del nombre para saber si es función/clase/variable, etc
Sobre el tip 4 en C/C++ existen los enums con valores por defecto, que sería lo mismo que un diccionario, muy utiles. Grande Antonio.
en java tambien estan!!!
En typescript también!
Muy bueno lo del Early return, lo vi varias veces usado y no entendia porque lo hacian, gracias!
Me has animado a darle una revisada a javascript y node, yo es que no soy desarrollador, pero si cargo mi arsenal en pendrives para ahorrarme varias horas manuales en la oficina. Habrás encontrado alguna herramienta que se asemeje a pillow de python en js? Felicidades por como ha crecido el canal y sobre todo el contenido!
muy bueno, muchas gracias! bien venidos los consejos!
Excelente vídeo!!! Tus explicaciones son bastante detalladas y claras.
Apoyo para que hagas más vídeos de estos, siendo jr. me ayuda muchísimo.
Excelente!!! Gracias por el video. Saludos desde Buenos Aires Argentina!
Por temas de atomicidad, esta manera de encararlo es mas rapido pero en caso de haber un error en el proceso se ROLLBACKEA toda la transaccion, al hacerlo de manera poco optima estarias asegurando la atomicidad de todos los datos (solamente no se insertaria el o los valores erroneos, no se descartarian todos los datos)
he programado por dos años (por hobby) en proyectos propios... pero todos los consejos me sirvieron mucho!.... por ahí no tanto el de CSV a SQL, pero si piensas en la teoría de lo que has dicho igual se aplica a muchas cosas más (simplificar el código para que todo entre, de ser posible, en una sola línea de código)... espero que saques nuevos videos así!
Simplificar no significa reducir la cantidad de líneas de código. Lo importante es que sea fácil de entender, fácil de mantener y fácil de modificar.
Me gustarian mas videos de este estilo, muy bueno, grandee
10/10 super el video tome nota de todos los consejos , los aplique en un proyecto y la verdad que se nota la diferencia. Sigue con videos asi. Slaudos
llevo mas de 2 meses tratando de aprender progrmacion y siento que no aprendo nada con este video me has echo entender varias cosas y seguire intentado aprender js mas a profundo que es lo que me interese ay html y css
Que buen video bro! saludos desde las tierras caribeñas de Colombia!
Video increíble de mucha ayuda para los que están empezando espero que haya segunda parte. Eres un crack.
asi es muy bueno
Tu amor por la perfeccion es fantastica
tambien puedes crear chunks de N registros y ejecutas por bloques los querys de INSERT
Que buenos pro tips Antonio, El pattern matching fue mi favorito junto con los objetos y diccionarios y también sobre los DocStrings, Rust rules!
Excelentes consejos, muchas gracias por compartir
“Parsear visualmente” jajajaja que bueno, lo mejor es que te he entendido perfectamente
Un Linter vendría bien para un estándar de código y si no lo hay pues sugerirlo en tu trabajo, os ahorrares muchas discusiones de punto y coma, comillas dobles o simples y esos dilemas os lo aseguro 👍
Discúlpame si me equivoco, pero en el primer ejemplo no seria mejor manejarlo dentro de una transacción, porque el tema de conexiones a la DB se puede mitigar configurando un pool de conexiones. No es lo mismo realizar miles de registros uno por uno que hacer miles de registros dentro de una transacción usando únicamente un solo commit.
No puedo creer que en serio me quedé 1/2h viendo este video. Estuvo buenísimo. Like y suscrito ¡Muchas gracias!
Muchas veces pongo dos IF anidados en lugar de un AND porqué se lee mucho mejor la condición y el compilador lo optimiza así que no hay problema.
Hola Antonio, como siempre buenos videos, sólo un alcance; para hacer un insert de un csv más y más pro, puedes usar el load data de mysql, con php se puede y mucho más rápido y eficiente, yo lo ocupo para cargar archivos de miles de registros cada hora y la base ninse inmuta... eso no más, gracias por los videos
Tremendo contenido! Justo he estado pensando en cómo hacer una query con un archivo .csv a una base de datos y has dado justo en el clavo!
Vamos papi. Otro video
25:20, he trabajado en proyectos medio grandes de Python y eso se lo pasan por el forro.
En este ultimo discrepo bastante, para mí no harás el "ridiculo" solo tienes que adaptarte al proyecto y con las personas con las que estés trabajando, ya que hay bastante mierdisenior que obligan a los juniors a trabajar con la nomenclatura que ellos digan xd
Si está hecho está hecho, no vas a cambiar todas las variables de un code base gigante solo para seguir un estándar. Si empiezas un proyecto nuevo en 2022 y pones camel case en Python pues hombre, será porque quieres porque otra razón no hay jaja. Pero yo he visto de todo gente que mezcla las dos cosas en el mismo proyecto por ejemplo.
@@AntonioSarosi Tienes toda la razón, por cierto, para cuando creando mi propia distro de Linux? Saludos crack
Que buen vidio! Antoniooo
Me gusta como en el min. 15:30 ya te anticipas a los comentarios y preguntas, y de una vez muestras la extensión jajajaja, se me hizo gracioso. Pero si, ya lo instale igual 😆
Me he tardado en verlo (lo tenía pendiente) pero me encantó, estaría genial una segunda parte
buen consejos amigo. bien explicado. y con ejemplos. no solo habla. sino que tambien muestra como usarse. que bueno.
Mas videos como este, en serio... Buenísimo!
Muy buen video, otra cosa que veo hacer a mucha gente, incluso con experiencia, es poner condicionales ante boleanos en vez de devolver la expresion boleana directamente. Un saludo!
Mola este vídeo! dale con más tips!!
Este men es un boss. Le veo un futuro tan brillante que vas a necesitar gafas de sol para mirarle
¡Excelente! - ¡Buen trabajo Tony!
Vamoss por mas... falta esto en youtube.. te sigo crack..
una mejor manera de realizar inserciones grandes a la base desde un orgien como un csv o un txt es realizar un load data infile, es casi instantanea la insercion de tus registros.
Genio me sirvió mucho el vídeo para el día a día 😁 saludos desde Argentina y seguí así!
Justo podía llegar a necesitar algo así para una aplicación que estoy creando, pero en mi caso tengo los datos en un JSON. Muchas gracias!
Excelente datos!!
Algunas veces el insert involucra varias tablas, en esos casos debemos hacer mas trucos, pero siempre es mejor aplicar estructuras enves de ciclos
Buen video! Sí me gustarían más videos así!
Tremendo Antonio!
Bárbaro! Buen video bro
Con el Tip numero 1 acordaros de utilizar "TRANSACTIONS" si el gestor de la BD lo permite, y con un número de registros ni muchos ni pocos.
Ufff bellísimo... nada de esto métodos lo habia visto antes ... están buenisimos
Muchas gracias por tu consejos, han sido de gran ayuda
Grande Sarosi, nice video
VIDEAZOO!
muy buenos tips, soy nuevo en el mundo del desarrollo y me van a servir bastante en mi carrera profesional.
Muy buen video con grandes concejos !!!
Rust ahora tiene los std::collections::HashMap para hacer frente a la necesidad de usar diccionarios. Útil para 19:55.
24:40 "camel case pero empieza en mayúscula" - te refieres a PascalCase supongo 🤣
Excelente vídeo y explicación
Visto en 04/11/2022
Que buen video amigo, toma tu like
Muchas gracias por este video, nos ayudas a muchos ❤❤
Lo de retorno anticipado se le llama clausula de guarda si mal no recuerdo
Claro eso es un guard clause, se usa en los early return pero no se refiere a exactamente lo mismo. Los guards son los ifs que vas poniendo para cubrir edge cases, early return es simplemente el hecho de retornar pronto si no puedes seguir. Creo que no hay un término exacto, yo lo puse en Google y salía retorno anticipado jajaja
@@AntonioSarosi Esto al final es como todo en este mundillo, diferentes nombres para cosas similares. Buen Video
un video muy chulo.... aunque muchos los conocía volverlos a escuchar siempre es bueno
Muchas gracias, me gustan este tipo de videos, haz mas de este tipo, saludos desde Colombia
Al 'Early Return' también se le conoce como clausula de guarda.
hey muchas gracias por tus aportes
Muy bueno Don Antonio! jej
sigue así, esos temas están guapos.
Cuidado con quitar los if dentro de if.
Hay lenguajes que no garantizan que se evaluen de izquierda a derecha como c++ hasta hace un par de estándares, y como la expresión de la derecha únicamente se pueda evaluar si la primera es verdadera vas a tener buenos errores.
De hecho me pasó en una práctica de implementar protocolos de nivel de enlace en c++ que no le funcionaba a la profesora porque usaba una version de gcc anterior y en una parte que comprobaba si un puntero no es null y luego consultaba un valor lo hacía al revés dando un index out of bounds.
Sí en esos casos te la puede liar. Si tienes que retornar se puede poner en ifs distintos uno después de otro, no hace falta que este uno "dentro" de otro.
de hecho en la sentencia sql esta el bulk tambien, sin embargo esta bien lo que comentas.
Básicamente puros consejos de un día a día de un senior dev
No es que múltiples inserts sean más lentos, es porque para cada insert se abre y cierra transacción.
Si abres una transacción y sólo la cierras después de enviar los 100.000 inserts, es incluso más rápido que la solución que comentas.
Claro, el hecho de abrir y cerrar una transacción implica mucho trabajo si lo haces 100 mil veces en vez de una vez
no me sabia el de continue bastante util tu video :D
Buenos trucos, el del early return me gustó. Me lo habían contado, pero ahora lo entendí.
un if dentro de un if hace exactamente los mismo que un and en el compilador y en el peor de los casos junto a la indentacion se lee mejor el codigo y el rendimiento es exactamente igual
Qué onda con la propaganda de youtube? Ponen un anuncio cursi de cocina eterno dentro de un video de programación :(
&& no es “and” (poca gente lo sabe) es “and also” que tiene un comportamiento diferente
Excelente video!! Saludos desde colombia
tips para ser menos noob, me gusta, te compro la idea, siempre está bien aprender más :)
Thanks Maquina!
Algunas me las sabía otras no, buen video Antonio
Más vídeos de este tipo a ver si llego a semi senior rápido XD
Buenísimos tips 👌👌
muy bueno, esperamos parte 2
Bravo Antonio 👏
muy buen video, aprendi mucho
¡Qué tal Antonio 👊🏼. Muy interesante la serie!
Para el primer tip, lo suyo sería usar la herramienta de la base de datos que estes utilizando para hacer cargas masivas, como SQL Loader
Es verdad, pero el tip creo que podría aplicarse si algún usuario de una aplicación necesita cargar un archivo con información. No quieres que tenga acceso directo a la db y por lo tanto podrías crear esa funcionalidad