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.
Douglas (00:00)
yo le daría prioridad a la base de datos antes que a otras cosas. yo les daría prioridad a la base de datos, arquitectarla bien, estructurala bien, normalizarla, y puedes usar PHP si querés, puedes usar
si querés y vas a tener un resultado más grande a que usés Go o cualquier lenguaje que te parezca que está de moda y tengas una base de datos que no esté efectiva.
Juan (00:15)
jajaja
Bienvenidos sean todos a su podcast favorito de tecnología en español de nuestra región en Latinoamérica. Quiero ser muy específico en eso. Este episodio lo tenemos con mucho entusiasmo el día de hoy. Vamos a grabar un tema bastante interesante desde mi punto de vista, un tema que en mi experiencia veo que muchas veces no se le da importancia y luego a la larga empezamos a ver.
cuáles eran los problemas de no haber seguido estas cosas. Pero pero bueno, antes de entrar en materia, me gustaría también darle la bienvenida a mi buen amigo Douglas, quien siempre nos acompaña para darnos su punto de vista y me ayuda aquí con el la coautoría de este podcast. Cómo has estado Douglas? Cómo te trata la vida el día de hoy?
Douglas (01:19)
Hola Juan, pues siempre bien por la gracia de Dios, siempre contento de tener estas conversaciones con vos. Recientemente hablábamos, Que todas las conversaciones que hemos tenido en estos episodios, no ha habido una sola en la que hemos dicho uno o el otro, qué aburrida esta plática, ya quiero que termine. Y entonces, eso lo digo porque demuestra que en efecto vengo con mucho entusiasmo a esta plática, a esta conversación.
y como dijiste la intención es tratar de aportar valor vos y yo pasamos un buen tiempo porque la plática es muy entretenida para nosotros pero queremos que las personas que nos ven y nos escuchan puedan recibir valor y ⁓ venimos con toda la intención de seguirlo haciendo
Juan (02:05)
Es correcto. verdad es para nosotros todo este tema y todos los temas que hemos tocado son muy interesantes y yo creo que si estuviera en nuestras manos seríamos como el meme famoso de Barack Obama donde se está poniendo la medalla del mismo porque para nosotros es el mejor podcast de tecnología en Pero bueno, para tampoco aburrir a nuestra audiencia vamos a entrar en materia rápidamente.
Douglas (02:26)
sí
Juan (02:35)
Como mencionaba, el tema es muy interesante y quiero darles de lo que queremos hablar el día de hoy es sobre las mejores prácticas que he encontrado para trabajar con bases de datos desde el punto de vista de un desarrollador. Hago la aclaración porque si alguien es está trabajando como DBA o database administrator, pues claramente las cosas cambian. Un administrador de bases de datos debe tener mucha más.
¿Cuál sería la palabra? Mucha más seguridad, mejores prácticas y todo, ¿no? Más rendimiento, un mayor enfoque en todo lo que tiene que ver con la base de datos. Pero, eso no quiere decir que nosotros como desarrolladores tenemos que utilizar la base de datos como un cajón donde guardamos muchas cosas y listo. La verdad es que ese es un problema que suele darse con mucha frecuencia.
Douglas (03:12)
Rendimiento.
Juan (03:34)
y creo que no debe ser así. Así que por eso voy a mostrarles o hablarles sobre algunos tips y recomendaciones que creo que vale la pena tenerlas en cuenta siempre, siempre que estamos trabajando con bases de datos. Claramente, para los que ya no siguen de episodios anteriores, sabemos que el trabajo de Douglas va orientado a otro tipo de casos, pero aún así,
Douglas, por si no lo han escuchado en algunas pláticas anteriores Douglas siempre tiene que ver y está trabajando muy de cerca con las bases de datos así que estoy seguro que Douglas te has visto en algún momento estoy seguro que le has echado rayos a algún desarrollador que está haciendo que trabajes de más con algún problemita de bases de datos no es necesario que digas ningún nombre ni nada pero
Pero te ha pasado? Yo apostaría que sí.
Douglas (04:32)
No te equivocas, mira, no te equivocas. Si trabajo de cerca con bases de datos, de hecho mi día a día incluye mucho bases de datos, sin embargo no soy un DBA, no soy un administrador de bases de datos, estas personas son todavía un poco más profundo en ese sentido, o tampoco soy un desarrollador de bases de datos, no, estas personas que hacen, que te hacen store procedures y diferentes queries y escribes y este tipo de cosas, pero sí, siendo alguien que se encarga de los
servidores de base de datos del performance, he tenido situaciones en las que cuando...
un developer tiene problemas que parece que debería de ser alguien experimentado y parece junior y que por cualquier cosa se manda a hacer un request a la base de datos que tiene queries que son insanos son completamente locos que hace la misma petición o el mismo query o el mismo llamado una y otra vez cuando miro ese tipo de cosas que me tiene que llevar a agregarle más recursos a un servidor solo porque alguien no implementó
mejores prácticas realmente que se vuelve un poco frustrante de mi parte. He aprendido con el tiempo Juan hacer un buen colaborador o sea hacer un buen team mate, buen compañero y empezar a sugerir cosas, acercarme de manera productiva, de manera de enseñar, explicar o que esperamos nosotros en sistemas como mejores prácticas porque por mi lado voy a aprender mucho ahorita de lo que vos vas a decir porque yo soy bueno en saber qué pedir.
en saber qué quiero, ¿no? O qué no quiero que hagan. Pero en realidad, ¿cómo hacerlo? ¿Cómo llevarlo la práctica? Pues no mucho, muy poco en realidad porque no programo. Pero sí, realmente que al final, aunque le he tirado rayos y centellas a varios desarrolladores, la intención es colaborar. Y para eso estamos.
Juan (06:30)
Sí, claro, la idea es, pues, la cultura DevOps se trata de eso, de colaborar y acercarnos los equipos de sistemas y desarrolladores. Es interesante lo que mencionas, Douglas, porque realmente de eso se trata. No vamos a... No voy a darles tips de cómo hacer store procedures o funciones dentro de la base de datos, que claramente son buenas prácticas también.
pero yo creo que a veces se tiene esta mala percepción por muchos desarrolladores que bueno, tengo que aprender a hacer estos procedidos para realmente hacer un mejor performance y no, hay muchas otras cosas que podemos hacer y dependiendo de la responsabilidad que tengamos al momento de crear tablas, columnas y todo esto pues vamos a tener que implementar estas prácticas en mayor o menor medida porque también hay que
hay que reconocer que hay muchos equipos de trabajo donde los desarrolladores definitivamente no hacen nada que tenga que ver con queries, no hacen nada con los esquemas de las bases de datos, pero hay otros donde sí, hay otros donde es un poco híbrido y hay otros donde tienen el total y absoluto control de los queries y de los objetos que se están creando en la base de datos.
Así que, bueno, los tips que voy a dar van orientados a ese público donde está en nuestra responsabilidad crear las tablas, las columnas, los queries y tal vez el DBA se encarga pues de darle mantenimiento y ver que todo funcione. A veces también hay ocasiones donde los developers hacen todo, los queries, tablas, etcétera, pero...
el DBA es quien da el punto y el visto final, DBA es quien acepta o rechaza dichos queries eso también suele pasar muy seguido así que voy a empezar con algo bastante bueno debo mencionar también antes de iniciar que estoy seguro que muchas de estos puntos que voy a hablar van a haber muchos que ya los conocían ya lo sabían pero
Irónicamente Douglas, son cosas que yo veo que no se implementan por desarrolladores que están trabajando con bases de datos. Como digo, lo más normal es que utilizan a las bases de datos como un repositorio donde todo va parar tal cual como lo crearon. Y en este caso me gustaría empezar con lo más fuerte, creo yo, y es el tema de la normalización de las bases de datos. Entonces, ¿qué es normalizar?
vamos a partir de ahí, es normalizar el esquema de una base de datos. Normalizar, dicho en palabras mías, palabras muy simples, es poder seccionar la información que estamos guardando en la base de datos de tal manera que podamos evitar la repetición y la duplicidad de datos. Hay diferentes formas normales.
Por cierto, voy a ir hablando Douglas, si me querés interrumpir en cualquier momento lo podés hacer. Tenemos varias formas normales. La primera forma normal es cuando tenemos una base de datos donde estamos guardando la información tal cual. Y aquí empezamos a ver prácticas que suelen darse donde tenemos, por ejemplo, en vez de tener múltiples columnas, tenemos una columna.
Douglas (09:47)
Dale.
Juan (10:09)
donde separamos múltiples valores por una coma eso suele pasar muy seguido o donde tenemos en una celda tenemos varios valores que están pues todos agrupados y esa es como ok está bien estamos iniciando estamos empezando a diseñar nuestra base de datos y al inicio de hecho es algo que yo he hecho de fino bueno voy a hacer mi tabla de qué se yo facturas y pongo todos los datos que creo que tiene que tener una factura
y luego poco a poco empiezo a normalizarla y a pasar al siguiente nivel. El siguiente nivel seria pues la segunda forma normal y es el hecho de separar estos valores que Aquí es donde es necesario analizar muy bien lo que estamos guardando Douglas. Realmente vale la pena dedicarle el tiempo suficiente a
diseñar la base de datos que queremos tener. veces por tiempo, a veces por presión de nuestros superiores. Puede surgir, pueden haber casos donde empezamos a, ¿cuál sería la palabra que estoy buscando? Entregar, esa sería. Entregar un trabajo que no está completado, no está en su forma final, como diría Freezer.
Douglas (11:29)
Mm-hmm.
Juan (11:38)
Pero vale la pena darle el tiempo y en este caso, pues como menciono, la segunda forma normal hay que ir separando las diferentes entidades. Si antes yo tenía, vamos a dar un ejemplo rapidito, si yo tenía una tabla que decía cursos, cursos de materias y ahí yo tengo guardado el nombre del estudiante, el nombre del curso y cuáles son las diferentes temas dentro del curso.
y todo está en una sola tabla, los temas están en una columna separados por coma y se empiezan a repetir valores pero funciona. Bueno, la segunda forma normal nos indicaría que empezamos a sacar entidades. Ok, ahora quiero tener la entidad de curso, parte. Entonces tengo la entidad de usuario o estudiante, también esta parte. Y ahora dentro de la otra tabla tengo pues
una referencia al id del usuario, al id del curso pero tal vez sigo teniendo las entidades de los temas están separados por columnas puede funcionar y luego tenemos la tercera forma normal y es donde ya todos los valores deben estar nada más que referenciados ahora yo voy a tener la tabla de estudiantes, la tabla de cursos, la tabla de temas de curso
y así empiezo a seccionar lo más que pueda todos los diferentes valores que pueden existir en mi base de datos. Esto es complicado, debo admitir que dependiendo de la lógica de negocios o dependiendo de la aplicación que estemos realizando puede ser más o menos complicado, pero como dije, vale la pena tener una estructura que sea resiliente en el tiempo.
¿Qué quiere decir esto? No quiere decir que no vamos a hacer cambios a nuestra base de datos, lo que quiere decir es que cualquier cambio que queramos introducir va a ser posible debido a que ya previamente hicimos un estudio y tenemos un esquema que admite cambios, ya sea... idealmente no quitaríamos valores, pero pues tal vez quitar o poner o agregar más cosas. Esto es una de las primeras cosas que...
muchos desarrolladores omiten dudas creo que la excusa sería que pues somos developers no somos DBAs pero aún así yo creo que vale la pena estudiar este tipo de cosas porque como lo decía antes un jefe que tuve anteriormente él decía quien hace la base de datos es quien realmente hace la aplicación
Y hasta cierto punto, pues, tiene cierto sentido, ¿no? Porque eso es lo que dicta cómo se va guardar la información. Eso es lo que dicta cómo vamos a interactuar en la aplicación. Pero bueno.
Douglas (14:43)
Por ende, entonces,
quien entiende la base de datos también entiende la aplicación. Le conviene al developer entender bien la base de datos, no si seguimos esa premisa.
Juan (14:49)
Sí.
es correcto. De hecho me ha pasado donde estoy trabajando en un producto dentro de la empresa y luego tengo que ir a otro producto que no conocía y llego a la base de datos y pues como es de esperar al inicio no entiendo nada, no sé dónde se guarda la información y sí puedo leer el código, le entiendo al código pero no me hace click todavía porque no conozco la base de datos tengo que ir revisar la base de datos revisar el código también obviamente pero pero bueno todo va de la mano
es inevitable. Más cuando estamos del lado del backend, la gente de frontend creo que puede lavarse las manos, aunque en mi opinión Douglas, también tienen que conocer cómo está estructurado porque eso te permite saber qué información puedes obtener y cuáles deberías mandar. Creo que las personas de frontend también deben conocer la base de datos aunque bueno, siempre se pueden lavar las manos también.
eso suele pasar pero bueno, son las formas normales Douglas hice un resumen super super rápido yo recuerdo en la universidad cuando vi este tema fue fue un tema de muchas semanas hablando sobre las diferentes formas normales de normalizar en una base de datos así que lo recomiendo a todos los que nos están viendo si no conocen este tema
estudienlo, búsquenlo por aparte, más detenidamente cada uno de los diferentes ítems que hay. ¿Has escuchado estos conceptos anteriormente Douglas? No sé si te ha pasado donde encontrar bases de datos donde en una tabla está todo guardado automáticamente.
Douglas (16:39)
Sí, no, mira, por supuesto, por supuesto, conozco los términos, los conceptos, y sí, me he topado con tablas que hubiesen hecho en Excel, mejor, ¿no?, y me hubiesen tirado todo ahí, ¿verdad? Pero fíjate que me llamó la atención algo que dijiste, es que yo le he compartido, realmente que llegar a este tercer nivel, donde solo existen...
Luego, como estas tablas de referencia prácticamente, donde solo estamos agarrando el ID de cada cosa en esa tabla, prácticamente, llegar a ese punto yo siempre he pensado que es más fácil decirlo que hacerlo.
porque no, y entre más segmentamos algo, más complejidad se introduce. Obviamente se vuelve más robusto, más, más, va a permanecer por más tiempo, más flexible ante los cambios y obviamente el consejo que estás dando es de llegar ahí a ese punto, pero sí me he topado con problemas donde tenés, por ejemplo, una base de datos con, que en la factura guardaron el nombre del,
Juan (17:20)
Sí.
Douglas (17:49)
el nombre del cliente, verdad, cuando el nombre del cliente ya está en la tabla de clientes y solo tenía que poner el ID y eso Juan, aunque no lo creas, ya me ha tocado a mí hacer audits de base de datos que están agarrando bastante espacio y con quitar ese tipo de columnas repetidas cuando estamos hablando de cientos, de miles, de registros, comienzan a ser significativos, no solo en espacio de discos sino también en rendimiento. Es que es lo que pasa Juan cuando hacemos
la
típica aplicación cita de tu dulis en mi local que sólo yo estoy probando no hay ningún problema no o voy a subir mi sitio web mi blog al internet y tengo tres visitas al mes no hay ningún problema pero cuando tenemos cientos de miles de recuesas a la base de datos en un día o en semanas esa columna además genera más almacenamiento en disco que genera más uso de memoria rama al momento de hacer de ejecutar queries
Juan (18:25)
Sí.
Douglas (18:49)
que genera más consumo de cpu y de iod en disco al momento de leer y escribir, verdad? entonces por eso cuando estamos hablando a ese nivel lo que está diciendo vos es muy crítico, muy importante, reconociendo, ya lo he pensado vos y yo, que llegar a ese tercer nivel ya se necesita de un nivel más avanzado, de alguien con un conocimiento más avanzado, pero igual concuerdo con vos
Juan (18:54)
jajaja
Douglas (19:15)
Al momento de arquitectar una aplicación, una solución, yo le daría prioridad a la base de datos antes que a otras cosas. O sea, estás pensando que no quiero usar PHP, que JavaScript es bien complejo, y lo que sea que se te ocurra y que te quieras regar, realmente yo les daría prioridad a la base de datos, arquitectarla bien, estructurala bien, normalizarla, y puedes usar PHP si querés, puedes usar
si querés y vas a tener un resultado más grande a que usés Go o cualquier lenguaje que te parezca que está de moda y tengas una base de datos que no esté efectiva.
Juan (19:47)
jajaja
Sí, sí, la verdad es que influye mucho en el performance a larga o a gran escala. Hay algo que mencionaste y me gustaría hacer como una nota sobre ello. Cuando mencionabas lo de en una tabla de facturas, tener el nombre de una persona. Esa parte creo que es válida poder tener solamente guardar el ID del cliente, del usuario, etcétera. Pero aún así, y eso lo que iba a mencionar al siguiente ahora, es que es...
están las formas normales de la base de datos pero a veces esto también se puede romper no necesariamente tienen que ser así siempre y todas las veces porque hay ocasiones donde no queremos esto si necesitamos duplicidad de datos y el caso más fácil de ejemplificar es con las facturas porque yo podría... que pasa si yo en vez de guardar cuanto costaba un item, un producto guardo el ID del producto funciona
pero que pasa si luego ese producto cambio de precio? bueno, cambio de precio hoy pero la factura que hice hace dos meses tenía el precio anterior entonces lo que queremos ahí es guardar cuál fue el precio que tenía cuando se compró cuando se efectuó la factura así que hay casos definitivamente hay casos donde sí vamos a tener que guardar columna por columna el valor que tenemos tal cual como estaba porque
nos trae más beneficios tenerlo así que empezar a normalizarlo. Pero de nuevo va de casos a casos y hay que irlo analizando poco a poco. Y lo último que quería mencionar con lo que estabas hablando, el tamaño y las escrituras que se van dando cuando hacemos un query muy grande y tenemos muchas columnas, a veces, cada vez yo creo que es menos o quiero pensar que lo hacen menos los desarrolladores.
pero pues una regla de oro es siempre evitar el select asterisco porque no queremos traer todas las columnas siempre hay que hacer un select de las columnas que realmente necesitamos y si más adelante necesitamos otra columna bueno hacemos un nuevo PR, un nuevo commit y agregamos la columna que queríamos pero bueno eso es lo que siempre tenemos que ir teniendo en cuenta voy a pasar al siguiente tip
Douglas si te parece, este es un consejo que de nuevo parece lógico cuando lo vemos en retrospectiva pero a veces no sé, se nos olvida o por conveniencia o por rapidez no lo hacemos de esta manera y es elegir el tipo de dato correcto para la columna que estamos utilizando podemos utilizar muchos tipos de datos ya sabemos, un int también tenemos un bigint
tenemos un bar chart de 255 o podemos tener un bar chart de tamaño 10 podemos tener un ID que sea numérico o un ID que sea de tipo string, un UUID cada uno de estos cumple con una función en específico no es que un dato sea mejor que el otro porque si fuese el caso pues todo lo guardamos como un número entero de 8 dígitos
esa es la forma que tendríamos más eficiente, pero no, lo que queremos es guardar lo que necesitamos de la manera más óptima que podamos. Por ejemplo, un boolean a veces cobra más, perdón, un entero puede ser más menos eficiente que guardar un boolean dependiendo de la base de datos que estemos utilizando. A veces utilizar un tipo de datos que sea muy grande para un
que ya sabemos que no va a sobrepasar ciertos límites pues ahí estamos desperdiciando tamaño en el disco, operaciones y pues todo lo que necesitamos para que funcione la base de datos. No sé por qué, como mencionaba, a veces creo que es por la rapidez, porque es más fácil, a veces también es porque utilizamos herramientas que generan las columnas de las tablas que estamos creando, también suele pasar eso.
Pero de nuevo, este es un cambio que podemos hacer y no cuesta nada. Simplemente es seleccionar cuál es el tipo de datos que necesitamos. Necesito un tipo Date o un tipo Date Time. ¿Cuál de los dos realmente es el que voy a estar utilizando? Entonces es necesario, ¿no? Pensarlo, darle el tiempo que se merece y utilizar el tipo de datos correcto.
recuerdo en cierto momento donde en cierta base de datos que trabajaba nosotros decíamos, desarrolladores, bueno, es que por qué utilizan un string como identificador único si un integer es más pequeñito, más eficiente pero bueno, con el paso del tiempo me he dado cuenta que a veces eso es mejor cuando tenemos sistemas distribuidos pues un UUID es mucho mejor
que un ID o una secuencia porque estamos trabajando con múltiples o diferentes tablas en diferentes bases de datos así que un UUID es la mejor opción que es un string y un string es más pesado pero de nuevo no se trata de cuál es más o menos se trata de cuál es el tipo de dato correcto para esa columna
Douglas (25:43)
Sí, quiero agregar algo porque me gusta lo que está diciendo y tal vez es consejo para las personas que nos vean y nos escuchan que pudieran estar comenzando en tecnología, en desarrollo, tal vez comenzar a guardar en bases de datos y crean una base de datos ahí medio genérica. Me gusta porque los consejos que está dando Juan son...
Juan (25:43)
vamos a pasar al siguiente... ⁓ perdón me decías
Douglas (26:09)
para aplicaciones grandes realmente, son, este tipo de aplicaciones son las que van a venir a sentir un impacto positivo o negativo por estas cosas, dependiendo si lo haces o no lo haces, porque lo que estás diciendo, el número de caracteres, por ejemplo, el tipo de datos, ya han sido recomendaciones que dado yo en audits de bases de datos, porque aunque parezca mentira, cuando hablamos de cientos, de miles de registros, millones de registros, hay una diferencia en que ser un query contra un carácter que solo está guardando un máximo de
de 5, 6 caracteres en un campo, un value, y tiene el Varshaar de 2.55 creo que es ¿no? Entonces, ¿para qué no vas a pasar de 5, 6 caracteres? Entonces, el consejo para estas personas es que presten atención porque vos dijiste algo que muchos lo van a encontrar obvio. Y sí, es cierto.
Juan (26:48)
Ajá, sí.
Douglas (27:02)
pero algunos lo podrán encontrar obvio y no lo pueden en práctica. O el que lo encuentra obvio no se da cuenta que ya tiene un recorrido tal vez en tecnología. estos consejos que está dando me parecen tan valiosos porque como no lo vemos...
En las aplicaciones que hago de prueba o de práctica, me parece de que Juan puede estar exagerando, ¿no? O se muere por, tal que sea, me lo acepte y funcione está bien. Pero cuando empiecen a entrar a un ambiente corporativo, a un trabajo donde tengan una base de datos que sea más ocupada, ⁓ más utilizada, ahí lo que ustedes hagan va a marcar una diferencia entre un junior y un senior, por ejemplo, ¿verdad? Entonces, me llamó la atención y quería dar ese consejo.
Juan (27:44)
Sí.
No sé si nos pudieras hablar un poquito sobre eso. Obviamente sé que hay datos que no puedes dar por la naturaleza y la seguridad de la empresa, ¿cómo suele ser una auditoría hacia la base de datos? ¿Es algo que empiezas a revisar las tablas literalmente o revisas los procesos que se están ejecutando?
Douglas (28:12)
Mira, me gusta la pregunta y me voy a enfocar tal vez en lo que va relacionado al tema porque hay parte, comienza con seguridad, verdad, y que desde que los usuarios tengan acceso únicamente a los esquemas que necesitan, acceso de manera interna o de los servicios que necesitan conectarte, justo la semana pasada encontré una base de datos que la tienen en una instancia de EC2 donde la IP pública está expuesta
Juan (28:21)
Ok, sí, sí.
Douglas (28:41)
internet.
y el puerto de MySQL está expuesto a internet, ¿no? Mientras estaba en llamada con el cliente, hice un telnet al puerto, a la IP pública y me conectó. Pero bueno, la seguridad es parte importante, pero en cuestión del esquema y de los datos, no es mucho relacionado en cuanto, en cómo está hecho el esquema, De la base de datos y que el diagrama y los índices así de manera general. Pero si nos enfocamos en el contenido, contenido repositor,
Juan (28:51)
Ok
Douglas (29:13)
repetido, verdad, en los queries que se están, los queries lentos, los queries que se están ejecutando, identificar dónde puede ir un index y es ahí donde te digo que a veces un query que está tomando bastante tiempo en ejecutarse con cambiar al tipo de campo correcto de un Barshot 255 al, hay unos pequeños, no creo que es el 8 o Juan 16.
Juan (29:37)
Si, le puedes asignar un valor más pequeño.
Douglas (29:39)
Entonces
creo que con solo cambiar eso, un query puede pasar de 8 segundos a 1 segundo, 2 segundos, porque estamos hablando de nuevo de un montón de records, ¿verdad? Entonces a medida vamos empezando a encontrar eso, vemos cuánto almacenamiento tiene la base de datos en disco.
las tablas que está teniendo, donde para nosotros es importante el contenido repetido, a donde empezamos a sugerir, tiene este contenido repetido, no le conviene, donde empezamos a ver índices, donde empezamos a ver los tipos de caracteres y luego empezamos a ver cosas como la configuración, cómo está configurado el servidor, cuánta RAM tiene comparado con cuánto pesa la base de datos, porque si tenés una base de datos que pesa 120 GB y tenés 4 GB de RAM, va a ser difícil.
porque tienes que cargar un porcentaje mínimo, entonces por ahí va orientado el audit y la mayoría de los audits que nosotros hacemos van orientados en contenido y en seguridad, ¿verdad?
Juan (30:31)
No,
Douglas (30:44)
Entonces, por eso es que lo que estás diciendo me resuena, Y por eso me parece que las personas nuevas que nos ven y nos escuchan es de mucho valor que presten atención a los consejos que están dando porque van de la mano con cosas que miro solo en bases de datos grandes. Por ejemplo, WordPress, ¿verdad? WordPress tiene su base de datos por defecto y hacemos mucho audit a bases de datos de WordPress.
Juan (31:04)
Sí.
Douglas (31:08)
Y encontramos problemas cuando alguien empieza o va instalar muchos plugins que encontró en cualquier lado, que empieza a crear un montón de tablas en WordPress, ¿verdad? O que tienen funcionalidad propia. Y empezaron a guardar en WordPress de manera incorrecta. Y es ahí donde se empieza a ver un problema y es ahí donde identificamos ese tipo de cosas. Hace como dos meses, empezando diciembre.
Juan (31:33)
¿Ok?
Douglas (31:34)
Como un desarrollador, un proceso que tomaba era importar información de usuarios a un sistema interno en WordPress. Un proceso que tomaba día y medio trabajando con el developer se redujo a hora y media. Y la mayoría de cambios...
fueron en base de datos, ¿verdad? Entonces, y había una forma, y cómo llamar, cómo conectarse a la base de datos. La mayoría de cambios fueron esos. Había unos loops y unas cosas que no eran culpa de la base de datos, pero la mayoría fueron parte de eso. Entonces, por eso te digo, es un proceso de tantos usuarios que ahí se siente.
Juan (31:58)
Ok
Douglas (32:19)
Aparentemente el programador que lo hizo, que trabajó para la misma empresa donde yo estoy hace muchos años, no había tantos usuarios en su momento y eso funcionaba.
Juan (32:27)
Ok, no era
problema.
Douglas (32:29)
No era problema, ¿verdad? Pero de repente empezó a tomar horas, horas, y ya iba por un día y medio y se le dedicó tiempo y ahí se corrigió. insisto, he insistido, estas cosas vienen a tener un impacto cuando hay bastantes usuarios, pero las personas que no ven y no se escuchan, ¿qué queremos? ¿Trabajar con proyectitos ahí en la casa o llegar a un punto de tener la capacidad de trabajar en proyectos grandes y empresas grandes? Yo creo que a eso le apuntamos, ¿no? Entonces, comencemos a implementar estas cosas que Juan nos está recomendando en nuestros proyectos hoy en día.
Juan (32:53)
Sí.
Sí, claro, porque también estoy seguro que muchas personas están tratando de hacer sus proyectos por aparte y alguna idea que tienen, ¿no? El nuevo Facebook están desarrollando por ahí. Y pues la idea es tener muchos clientes, muchos usuarios. Así que siempre vamos a necesitar esto. Muy interesante cómo hacen las auditorías de bases de datos, me llama mucho la atención. Bien, vamos a continuar entonces Douglas para ir entrando en...
Douglas (33:11)
Ajá.
Juan (33:27)
en lo que nos compete el día de hoy. El siguiente punto que quiero hablar o que quiero mencionar es uno que también es fácil pero aquí sí tenemos que programarlo por decirlo así y es cuando estamos agregando constraints a las diferentes tablas y índices que tenemos. Son las restricciones que vamos a agregar. Algo muy simple es un check. Estamos diciendo que
Bueno, en el tema de facturas yo espero que siempre el subtotal, el impuesto, el total y todo eso sean valores positivos. No quiero yo recibir una factura que tenga un valor negativo o tal vez sí, no sé cómo funcionará en cada una de las empresas, pero si lo que nosotros esperamos es que nunca, nunca, nunca sea un valor negativo, entonces agregamos el famoso cheque de la base de datos.
donde eso se va a evaluar al momento de hacer un insert, al momento de hacer un update también y la verdad es que es algo que nos puede salvar la vida. A veces puede fallar la lógica en la aplicación, front and back en todo esto.
pero pues la base de datos tiene que ser el último bastión donde se hacen las últimas pruebas tampoco bueno tampoco vamos a agregar cosas muy muy complejas porque recordemos en cada una de los queries en cada uno de los inserts se va a evaluar esto así que no queremos algo tan complejo pero sí podemos tener diferentes reglas que son más o menos complejas en el caso de postgres
nos permite tener cosas muy interesantes recuerdo en cierto momento estaba utilizando este servicio llamado Super Bass Super Bass utiliza Postgres y utiliza algo llamado Row Level Security si no me equivoco y te permite tener diferentes reglas al nivel de cada línea de cada row y podemos ir agregando como que cheques pero un poquito más complejos
de decir bueno esto se va a hacer o se va a efectuar solo si este usuario pertenece a este grupo de tal cosa de nuevo no hay que hacerlo tan complejo pero podemos hacer cositas que tal vez son un poquito va un poquito más allá no va a depender de cada caso pero la idea general es esa agregar diferentes constraints a nuestras tablas y índices que tenemos en la base de datos
Muy fácil de Douglas, estoy seguro que en algún proyecto que hayas trabajado, ya sea por tu cuenta o algo extra, habrás visto ese famoso ese ese keyword en la base de datos, el check y agregamos algo simple. Siempre siempre tiene que ser algo simple, como dije, se pueden hacer cosas por ahí. Sí, nos estamos quedando un poco ya entrando a la etapa final del episodio.
pero pues que vamos a mencionar un poco las que tengo por aquí. Me gustaría mencionar un otro concepto, otro tip que este no tiene que ver con la configuración de la base de datos, no tiene que ver con los tipos de datos, sino con la forma en que ejecutamos diferentes queries, diferentes sentencias.
Al inicio hablábamos verdadulas de los Store Procedures y estos Store Procedures me permiten a mi tener un bloque de código dentro de la base de datos que va a hacer idealmente múltiples cosas internamente. A veces, como no hacemos Store Procedures, pues nos escudamos en ese aspecto. Bueno, es que no tengo un Store Procedure, así que voy a hacer un insert a la base de datos, a la tabla de usuarios.
y luego un insert a la tabla de amigos y luego un insert a la tabla de qué se yo comentarios. Qué pasa si algo falla en medio de eso? Ahora tengo yo una transacción incompleta. Tengo data que hasta cierto punto, dependiendo de la gravedad del caso, es data corrupta. Entonces aquí mi consejo es que todo, prácticamente todos, todos los lenguajes de programación nos permiten ejecutar
estas instrucciones de manera atómica o en transacciones esa es la palabra utilizar transacciones en go en java en node estoy seguro también podemos utilizar transacciones a nivel de código son transacciones que no están en la base de datos pero estas librerías y estos paquetes nos permiten hacer eso en el código y la verdad es que es algo que nos va a ahorrar mucho
mucho, mucho, muchos dolores de cabeza. En cierto momento vi, hace tiempo vi y recuerdo un código donde tenía una lógica bien compleja porque hacía muchos inserts y uno que otro update si no me equivoco y luego verificaba que todo estuviese bien. Si algo no coincidía, entonces se ejecutaba las operaciones inversas, pero todos y cada una de ellas eran queries independientes.
muy complejo para lo que podríamos haber hecho una transacción donde si algo falla automáticamente hacemos rollback y fin del asunto, mostramos un error en la pantalla, etc. Pero bueno, hacer una transacción es algo que no es complejo realmente es muy muy fácil en todos los lenguajes y lo podemos implementar desde ya, podemos hacerlo. Así que utilizan transacciones, se van a evitar
muchos dolores de cabeza.
Douglas (39:25)
Ese no me lo sabía yo. En los otros acciónes.
Juan (39:28)
Sí, sí. A veces
se tiene la percepción de que solo puede ser desde la base de datos, pero sí, se puede hacer a nivel de código también.
Douglas (39:37)
Y ese será lo mismo, Juan, y aquí aprovecho de verdad una pregunta. visto situaciones en las que mejoraron rendimiento de nuevo cuando hay bastantes transacciones, ¿no? Donde en lugar de si vas a actualizar, digamos, un proceso, no sé, actualizar las horas que trabajó un empleado, ¿no? Entonces, en vez de tener tu proceso donde empleado, horas, actualizo.
update, al récord, empleado ahora update, que pasar por todos primero y luego hacer un solo update, he visto escenarios en los que hacer eso tiene un rendimiento mucho más alto.
que ir uno por uno. En algunos casos no ha generado ninguna diferencia porque ya he trabajado junto con desarrolladores en pruebas similares. Yo sé que aquí lo que estás hablando es una funcionalidad del lenguaje de programación, o entiendo la diferencia, pero hago la pregunta porque hay algo de similitud. estás hablando de hacer una secuencia y si falla en algún punto, El revierte ya había escrito en ciertas bases de datos, pero como no terminó de escribir en todas va a revertir en las que
Juan (40:44)
Sí.
Douglas (40:49)
había escrito, no eso es que vos estabas explicando, pero en este caso es primero hacer todo, las modificaciones y hacer un solo update o un solo insert, eso es algo relacionado o es algo que lo has trabajado por tu cuenta?
Juan (41:06)
si se puede también, de nuevo muchos quiero creer que todos los lenguajes de programación tienen alguna funcionalidad para hacer, si no me equivoco serían bulk, bulk, sentencias en batches también se le podría decir, es como hacer muchas, en vez de hacer un insert uno por uno, hago un insert de múltiples records de un solo y bueno, generalmente
eso sería más efectivo que hacer uno por uno. El motivo es que si lo hacemos uno por uno, a nivel de conexión estamos haciendo múltiples llamados a la base de datos. En cambio aquí estamos haciendo un solo llamado y le estamos enviando toda la información. De nuevo, casi todas las librerías o paquetes con las que interactuamos con la base de datos tienen alguna forma para hacer esto.
si estamos utilizando o si estamos guardando la información pues sí vale la pena hacerlo de esa manera en Node.js recuerdo haber trabajado de esa manera específicamente y bueno es Node.js entonces otros lenguajes estoy seguro que también lo tienen lo que me sucede a veces es que no lo queremos hacer así porque bueno dependiendo de la lógica del negocio a veces queremos que se detenga en cierto punto y me diga cuál es el que falló
y bueno algunas cosas así no queremos ir como chequeando cada uno uno por uno o tal vez tenemos que hacer algún una composición muy compleja entonces vamos línea por línea pero pues sí a veces también se puede hacer de en batches más grandes y como te digo es más eficiente porque es una sola llamada a la base de datos así que sí sí se puede
Douglas (42:54)
Sí, ok,
me gusta, o sea que sí es un consejo que puedes dar y sí entiendo esa parte, ¿no? Tienes un proceso que tarda, una hora.
y luego hace un insert y el insert falla, falló todo, ¿no? Pero si vas uno por uno, digamos, tarda hora y media, pero si falla la mitad, la mitad fueron positivas, ¿no? Lo reanudas. Entonces, no, puedo entender los pros y contras, pero me llamaba la atención porque de nuevo es una estrategia que se ha utilizado, que he visto que se ha utilizado, no ha sido iniciativa mía, y de nuevo he visto casos donde no cambia el tiempo, ir uno por uno o hacer todo de un solo, pero te agradezco porque tenía...
Juan (43:09)
Sí.
Sí.
Douglas (43:34)
saludos
Juan (43:36)
Sí, sí, claro, Bueno, ya estamos llegando al final del episodio ULAS, pero no me gustaría irme sin antes mencionar las últimas dos que tengo. Bueno, tengo varias por aquí, pero creo que estas dos pueden ser las más importantes que me gustaría hablar el día de hoy. La primera es siempre agregar columnas de auditoría. ¿Cuáles son las columnas de auditoría? Fácil. Una columna de cuándo se cree el registro, una columna de cuándo se ha actualizado.
y la famosa también columna de cuando se borró. Esta es muy útil porque en vez de tener una columna de activo, no activo o borrado, no borrado, que es como un soft delete que le llaman, pues tenemos una columna que se llama, qué se yo, deleted ad. Entonces esa es la fecha en que se borró y eso nos sirve también para verificar este archivo si está nulo, bueno, es un archivo o un registro válido.
Pero si tiene una fecha, entonces significa que fue borrado y al mismo tiempo me sirve para ver cuándo se borró. Entonces, ese tipo de información a veces puede ser más compleja, De qué usuario creo este registro y otro tipo de cosas que podemos ir agregando. Pero lo más básico, cuándo se hizo, cuándo se actualizó, ese tipo de cosas se pueden estandarizar en la empresa o en la aplicación que estamos trabajando.
y siempre agregar esas columnas a todas las tablas que tengamos en el sistema.
Douglas (45:02)
Pero eso quiere decir, Juan, perdón, que yo he visto cuando se creó y la última vez que se modificó y eso ayuda mucho, ¿no? Pero no había trabajado con cuando se eliminó. sea, quiere decir que el récord queda ahí siempre consumiendo espacio en disco, solo que queda inválido y me queda la fecha de cuando fue eliminado. Eso es lo que significa.
Juan (45:22)
Si es correcto, muy común, es la practica predominante en que no se borra nada de la base de datos, nunca borramos nada de la base de datos, ⁓ de hecho lo extraño o lo poco común es que si se borren los registros, literalmente el delete en ese QL, entonces lo que se hace es el soft delete
donde simplemente tenemos una variable que nos indica si está activo o no. Ojo, también hay variables o columnas que nos dicen si está activo, que tal vez puede ser que no está borrado pero está desactivado, bueno, dependiendo de cada empresa y de cada aplicación. Pero sí, con el delete marcas eso.
Douglas (46:10)
Ok, pero eso para mí tiene sentido con usuarios por ejemplo o transacciones porque si le da un usuario, que son sus transacciones, luego quien hizo esas transacciones, o eso tiene sentido, por ejemplo, vaya, te voy a poner como ejemplo contenido digamos del CMS de WordPress.
blockbox, el contenido del blockbox como tal, pues al eliminarse recomendamos que se elimine porque pues es contenido que ya no se va a necesitar. ¿Eso aplicaría ahí también o solo son registros como los que te mencioné, usuarios, factura y ese tipo de cosas?
Juan (46:44)
Normalmente aplica todo, normalmente no se borra nada de hecho dependiendo de si estamos certificándonos con diferentes normas, ¿cómo se llaman? ¿las normas ISO? Certificados ISO, no sé si es la 9000, 90001 o algo así, te exigen que no hubo que tengas este tipo de mecanismos así que de nuevo a veces pues
dependiendo de las decisiones que se tomen al momento de arquitectar la aplicación puede decir ok si se borra definitivamente se borra del todo pero lo más normal es que no se borran así que bueno en facebook cuando damos borrar a una imagen lo más probable es que no se borró ahí está todavía en los servidores de meta porque así es como funciona normalmente la industria pero sí
Douglas (47:36)
Ok,
solo voy a mencionar, me llama la atención lo que está diciendo, voy a mencionar que en cuestión de lo que es el contenido como tal, en un CMS o en WordPress en particular, nosotros en estos audits o cuando el sitio es grande recomendamos que el contenido como tal si se elimine de base de datos, de hecho, WordPress por defecto tiene que cada revisión que le haceja la...
a un post o a una página guarda el historial porque puede revertir en algún punto no es por defecto cada vez que vas a abrir eso
Juan (48:01)
Sí.
Douglas (48:08)
editar un blog post y le agregas un espacio y le das a salvar, él guarda otra versión y él lo va a hacer por la eternidad y puede terminar con 80, 300 revisiones de una página. Entonces, de hecho nosotros limitamos normalmente ese número, dependiendo del negocio a solo que guarde unas tres revisiones o cinco revisiones para que no se haga ese espacio en base de datos porque en lo que es de nuevo contenido como tal normalmente cuando ya no se necesita
Juan (48:28)
Ok
Douglas (48:38)
pues no es como algo a lo que se va a referenciar. Entonces, para mí tiene sentido de nuevo usuarios, facturas y otro tipo de registros que nunca se eliminen. Pero es la primera vez que me topo con este concepto y me está llamando mucho la atención y me sirve a mí para aplicarlo a mis cosas. Pero sí, quería comentar cómo nosotros manejamos lo que es contenido como tal. Cuando se decide en negocios que ya no se necesita ese contenido, recomendamos que se vaya a la base de datos.
Juan (49:07)
que curioso, es tan interesante porque lo que me estás diciendo para mí me parece muy bueno, nuevo la verdad, no lo veo tan común y de igual manera lo que yo te estoy diciendo para vos es como que wow, esto no lo había visto que curioso, la verdad pero bueno, en las diferentes empresas en las que he normalmente no se suele borrar lo más normal
Douglas (49:20)
Sí, sí, sí.
Juan (49:32)
Bueno me gustaría dar entrar entonces Douglas el último consejo que creo que vale la pena mencionarlo y este es uno que normalmente no tenemos en cuenta como desarrolladores. De nuevo como dije al inicio si hay un DBA que se encarga de todo esto pues bueno nos lavamos las manos pero si tenemos cierta responsabilidad en lo que se está haciendo en la base de datos hay que tenerlo en cuenta y son los índices compuestos.
ya sabemos que se pueden hacer índices, osea un índice es guardamos la referencia de una columna de un valor y eso hace que las búsquedas sean más rápidas no voy a entrar en detalles de cómo funcionan las bases de datos pero pues tenemos diferentes índices el índice del ID del usuario el correo del usuario puede ser un índice y bueno cualquier cosa podemos hacer un índice pero se suele hacer índices de aquellos valores que
buscamos más seguido. Pero también se pueden hacer índices compuestos, o sea un índice que está compuesto, valga la redundancia, por múltiples columnas, múltiples valores. Un ejemplo rápido sería el índice compuesto de el correo más, qué se yo, el rol.
el correo y la empresa, te digamos que es un usuario que puede dentro de la aplicación puede pertenecer a múltiples empresas entonces podría ser este índice porque nosotros ya identificamos que tenemos queries que se están ejecutando constantemente donde hacemos un where el correo y el id de la empresa entonces como ya tenemos esos where, esas sentencias where
pues ya podemos identificar los índices. Y aquí viene algo Douglas que me di cuenta al momento de estar preparando este contenido para este episodio. Esto yo no lo sabía. Y es que los índices compuestos tienen un orden. Imaginemos que tenemos un índice compuesto de tres valores. Como dije, el correo del usuario, la empresa del usuario, vamos a agregar otro ¿no? ¿Qué podría ser? No sé, la edad del usuario. Me estoy inventando cualquier cosa. El ID del usuario.
Douglas (51:48)
¿El ID?
Juan (51:51)
tenemos ahí muy buen ejemplo correo, empresa y ID pero yo los puse en ese orden en específico ok, que significa eso? si yo busco o hago mis queries con el correo y la empresa en ese orden ese índice compuesto aplica para esa búsqueda si yo hago mi query solamente con el correo del usuario todavía aplica el índice compuesto
Pero si yo hago otra búsqueda por el ID del usuario, ese índice compuesto ya no aplica porque no está en el mismo orden. Si yo hago, por ejemplo, busco el usuario por el ID y la empresa ya no aplica. Tiene que ser exactamente en el orden en el que se hizo el índice. Entonces, los índices compuestos son muy muy interesantes en ese aspecto porque nos pueden servir para múltiples búsquedas.
siempre y cuando lo hagamos en un orden correcto. De nuevo, esto yo no lo sabía, nunca lo había... nunca me había puesto a revisar ese tipo de cosas, pero así es como funcionan. Entonces, por eso quería compartirlo porque me parece que es algo que, bueno, yo voy a tratar de aplicarlo cuando tenga que hacer más tablas en la base de datos porque nos puede... en un solo índice tenemos varias optimizaciones al mismo tiempo.
Así que es muy interesante de mi punto de vista.
Douglas (53:19)
O sea que puede haber alguien ahí que hizo su índice compuesto, pero no estarlo usando porque el query no lo está llamando en ese orden.
Juan (53:24)
jajaja
Se puede, exacto,
puede desperdiciar definitivamente. Sí, sí. Y como te digo, es muy interesante porque tal vez el índice compuesto lo hiciste pensando en un query y tal vez resulta el efecto contrario. Ahora también está sirviendo para otros queries que no tenías contemplados porque el mismo índice está sirviendo a eso.
Douglas (53:30)
Y él dice, no me sirvió el índice, el índice. ⁓
Juan (53:54)
Así que, bueno, me pareció un dato muy interesante, no lo conocía y estoy seguro que les puede servir mucho cuando estén haciendo esto. Bien Douglas, por ahora nos vamos a quedar hasta aquí. De nuevo, tenía otros conceptos y otros tips por ahí escritos. Tal vez más adelante podemos retomar esta dinámica y verlos más detenidamente. Pero por ahora creo que estos eran los que si los aplican hoy...
mañana creo que les van a servir mucho y podemos ir aplicando mayor una mejor optimización a las interacciones entre nuestro código y las bases de datos no sé Douglas en tu caso qué te gustaría decirle la audiencia ahorita para terminar cómo te gustaría despedirte de ellos o si hay algún otro tip que en tu experiencia hayas visto
que hayas recomendado y que tal vez no lo hemos tocado el día de hoy.
Douglas (54:57)
Fíjate que mira, tengo...
Tenía dos puntos, el primero ya lo aclaraste que son entre actualizar todo a la vez o uno por uno y tengo otro tip que aplica a la ⁓ parte de sistema pero que viene del programador pero fíjate que lo voy a dejar ahí para que si hacemos un segundo episodio ahí lo voy a incluir por si alguien le interesa y queda con la duda y que nos dejen los comentarios, verdad, entonces lo voy a dejar por ahí y como
Juan (55:06)
Ok
Ok
Douglas (55:30)
comentario final quiero cerrar con repetir un poco el hecho de que en mi día a día si estoy trabajando con poco puede que no le encuentre beneficio a esto puede que comience a aplicar lo que juan me dijo y no le encuentre diferencia a mi sitio verdad
pero a medida se va exponenciando el uso, la cantidad de registros, la cantidad de requests, ahí es donde va a ser una diferencia. Vos dijiste algo importante, ¿verdad?, de, de cómo se llama, en conceptual y de cultura, y es que tenemos que entender la aplicación como tal, que los front-ends se pueden lavar las manos y no es una mentira, es cierto, ¿verdad?
Pero un buen front-end no debería, ¿verdad? Si quiere hacer un buen front-end y quiere llegar a crecer y quiere llegar a arquitectar soluciones en front-end, porque aunque no lo crean, las soluciones de front-end grandes se arquitectan también, ¿verdad? No debería de lavarse las manos. Entonces, estos son tips que son básicos, pero básicos de esos que se implementan.
día a día en aplicaciones de nivel enterprise. Son tips básicos que usan día a día en aplicaciones de gran escala. Piénsenlo de esta manera, si la forma en que solucionan problemas de rendimiento es tirándole más recursos,
Entonces, si la aplicación fuera de ustedes, ¿cuántos miles de están dispuestos a pagar para hospedaje? Si van a solventar los problemas con recursos, mejor intentemos que escorra con la mínima cantidad de recursos posibles para que a medida la aplicación crezca, nos ahorremos dinero. Entonces, ese es el pensamiento ⁓ con el que los quiero dejar.
Juan (57:17)
Me gusta, me gusta. Siempre el golpe a la billetera creo que es un golpe que nos ayuda a ponernos en perspectiva. Bueno, muchísimas gracias a todos los que han llegado hasta este punto. Dale a like por favor, un comentario. Todas esas cosas que piden los youtubers que yo he visto que aunque no lo crean si nos ayuda. que por favor pueden compartir nuestros videos si les pareció interesante, si les pareció de utilidad.
Douglas (57:24)
Sí.
Juan (57:47)
Así que nos vemos la próxima semana y muchísimas gracias a todos. Nos vemos.