❌ 7 ERRORES de Diseño en BASES DE DATOS 

Errores según mi experiencia 1. No aplicar normalización 2. No crear el diagrama de objetos 3. No carga la BD y hacer consultas 4. Que la BD no responda al negocio 5. No crear tablas de reporte 6. Crear tablas sueltas 7. No usar la columna tipo json 8. Crear la BD solo sin ayuda de nadie 9. No crear varios esquemas de BD 10. No crear una BD backup

Buenos tips aunque el punto #4 tengo mis dudas. Creo que hay ocasiones donde los valores calculados pueden ayudar, por ejemplo los sistemas de estadísticas y graficas. Calcular cada vez que se consulta todo un sistema de graficas mata el servidor y la aplicación en performance. El punto es no usarlo en secciones que requieran "Tiempo real". Reportes y Big data por lo general vas 1 día atrás 6 horas atrás etc...

ALELUYA, NO ESTOY LOCO!!!! NO ESTOY SOLO!!!! Hay más gente a la que le sangran los ojos cuando ven esas cosas T^T

Hola Manuel, Conforme al error #4 - Guardar información calculada. ¿Cómo lo manejarías en casos donde la BD guarde información de facturadas timbradas? Dígamos que los datos no deben cambiar

En el punto #4 de los cálculos hay que tener en cuenta que a veces la administración te obliga a facturar una determinada cifra pej. 2863,78€ . Pero al hacer el cálculo con tu progrma, por las aproximaciónes puede darte algo diferente ( 2863,80). Si tu envías una factura así te la van a retrasar y te pedirán una nueva. El tener que hacer pequeños retoques me ha ocurrido unas cuantas veces al año. Hay que tenerlo en cuenta porque podría discrepar los ingresos bancarios con la facturación, que en teoría debe cuadrar al céntimo.

yo agregaría varchar para todos los campos sin importa el contenido.

1. Guardar múltiples valores en la columna 2. No crear tablas lookup 3. Nombres que inconsistentes 4. Guardar información calculable 5. No crear llaves foráneas 6. Falta de índices 7. Falta de llaves únicas

muy bueno el video, como sugerencia tal vez el tema de salvar o como restringir concurrencias con la base de datos, ya que desde la nube llegan simultáneamente peticiones

Excelentes concejos profesor!, la verdad cuando uno va modelando su BD se da cuenta con el tiempo que pudo haber hecho las cosas mucho mejor al principio jejeje, muchas gracias por compartir tus conocimientos y experiencias!

Muy bueno tu video Manuel, solo dos cosas ene le punto 4 se pueden crear tambien campos calculados y el punto 6 incluiría índices non clúster ya que muchas busquedas y vistas son filtradas por campos que no son index esto hace que se haga un full scan a latabla, si se coloca non cluster index por varios campos , a la hora de filtrar por ellos todo ira mas rapido. saludos desde Barcelona

Excelente explicación. Gracias!

Como siempre muy buen video, con respecto al punto 6 creo que como Arquitectos o Ing de Software no debería ser un elemento que nos quite el sueño. Ya que (dependiendo del stack de profesionales de tu empresa) es el rol del DBA ir eliminando, actualizando y manteniendo los índices dependiendo de los diversos factores que señalaste (Uso, performance, etc). Y generalmente terminan alterando los indices que "pensaste" que podían ser útiles. Saludos.

en el caso de los lookup, yo genero un campo tinyint, ahí manejo el estado en númerico, para no estar consultando a otra tabla , ya en le código comento la descripción del estado

Que buen video, este tema de BD es algo muy interesante, si puedes seguir teniendo info de esta será muy chevere

Estaba en arquitectura de sistemas en un banco e hice varios estándares de programación, aquí lo escencial: Tabla, nombre en singular, ejemplo: Producto Identificador de tabla único(siempre) : ID_nombre_tabla_tipo dato Ejemplo: ID_PRODUCTO_BI BIGINT Y así para cada columna ..._VC varchar, ..._DT datetime, etc Es mucho más óptimo usar procedimientos almacenados y crear un procedimiento distinto para cada tarea Nombre de procedimiento : PRODUCTO_Insert, PRODUCTO_Select, etc En vez de almacenar JSON enteros en una columna, es mejor convertir a objeto desde la aplicación que consume la BD, así se crea una tabla para ese archivo/cadena JSON y es más fácil realizar consultas, sin necesidad de manejar cadenas dentro la aplicación

otro error pequeño, sería no acotar los campos a la longitud real que van a tener. Por ejemplo en mysql el tipo "int" es que pone por defecto para números enteros. Estos pueden ir desde -2147483647 hasta 2147483647, y muchas veces los números que necesitaremos no llegarán a ese rango, y hay otros tipos de números enteros que podemos usar con rangos más pequeños. También sería lo mismo para las longitudes de los varchar.

Excelente video, Manuel! Con un proyecto estaba cayendo en el error #2, lo resolví con una tabla lookup con PK nvarchar, porque ya tenía datos en producción. Estoy aprendiendo sobre índices para no cometer el #6.

Podrías hacer uno sobre errores en las consultas? y consejos. y excelente video, gracias

Buen video me ayudó mucho

Excelente video Bro. muchas gracias, muy buen material.

Manuel como estás? Te preguntaba por tablas gigantes que tratamiento les das ya que no veo nadie que hable de eso o hay muy poco. Ej. una tabla con 10 millones de registros como mostrar los datos. Me pasa también que veo mucha gente que se trae todos los registros y para mi es una mala práctica. Tengo ganas de hacerme miembro del canal nuevamente para conversar eso. Pd. no sé porqué ya no soy miembro si era y yo no me quise desunir. Ahora económicamente ando corto pero te aseguro que vuelvo. Saludos crack!

Gracias tío , me subes el autoestima en ocasiones tengo que discutir con pttomadores que diseñaron horrible sus base de datos

Te faltó agregar en el ERROR #5 al no crear llaves foráneas el otro problema es que al hacer un query con joins y si las tablas tienen muchos registros, esa consulta tardará muchísimo en retornar una respuesta. BUEN VIDEO! SALUDOS!

Muy buen video. Me ha tocado ver casos de no usar llaves foráneas; la explicación que le dieron era para no bloquear la aplicación. Pero recientemente me topo con ciertos casos donde hay que guardar valores nulos en campos ids. La única opción que se me ocurrió fue no ponerlos como llaves para poder guardar esos registros.

Hola Manuel, si son clásicos de las DB, agregaría algunos objetos que se "quedaron" por una migración o dejaron tablas temporales de regalo.

Buen articulo para quienes comienzan con bases de datos reacionales. En gneral se recomienda usar si o si hasta la tercera forma normal. Cuidado con crear índices para todos los campos ya que puede ocasionar el efecto contrario, especialmente en operaciones de escritura/update donde estas operaciones tienen que actualizar todos los índices en conjunto. Saludos!.

En mi experiencia agregaría, para el ejemplo que pusiste de guardar el valor total, usar funciones en los campos, esto es a mi parecer lo más potente de las DB y usar a fondo los diagramas de relación. Buen video, gracias.

Hola, excelente información. A raíz de este vídeo me surje una pregunta para dilemas de un desarrollador: ¿Cuándo usar una tabla lookup en vez de un tipo de dato enum en la columna?

Excelente video! Gracias por compartir 🙂 También es cierto que con la ayuda de los frameworks estamos menos expuestos a ciertos errores

Realmente no se mucho de bases de datos, digamos que... soy muy nuevo en ese tema.. PERO hay algo que me deja pensando, en el punto # 4 : por que no guardar los datos calculados en las facturas? en las empresas suele utilizarse el registro de ventas para hacer análisis financieros horizontales, incluso algunos clientes incluso logran tener precios especiales de venta sin contar como descuentos, entonces al tener un valor dinámico de precio final de producto como lo plantea el ejemplo pues es imposible hacer seguimiento.

Muy valiosa tu experiencia, muchas gracias. Saludos desde Argentina

Gracias por el video Manuel, siempre con buenos aportes.

Ahora ya entiendo cómo encontré tu canal, mucho antes de saber sobre la existencia de NullPointers. Estaba estudiando bases de datos y de los canales sobre el tema, el tuyo me gustó mucho. Vos sos caleño? Saludos desde medallo 🌄

Cuando mencionas el no guardar datos calculados, ¿te refieres a todos los casos? Porque hay situaciones donde esos cálculos no se van a modificar en el tiempo (ej. el total de una venta) o van a quedar solo como registro. En ese caso, ¿sería conveniente guardar el total calculado? Por otro lado, si el cálculo es muy complejo y se tiene que consultar varias tablas para llevar a un resultado, ¿cómo lo trabajarías o cuál es tu recomendación? Gracias por compartir tu conocimiento.

Saludos desde Brasil

Excelente video! Podrías hacer uno de base de datos no relacionales?

Gracias por la guía, muy útil para tener en cuenta al momento de diseñar nuestras bases de datos.

Para el caso 5 a veces sí es bueno guardar la información calculada por ejemplo una tabla audit o de history que se necesita ver un histórico.

Un añadido al de la tabla de estados, es que los profesores de mi facultad cuando me hacen diagramar UML, y despues llevar eso al DER de la base de datos, usan UNA SOLA tabla estado para todo lo que pueda necesitarlo, diferenciando a quien pertenece el estado usando una tercera columna llamada "ambito" (lo hacen asi por lo menos 3 profesores que estan graduados de ingenierieria en sistemas). Lastimosamente decirle que eso genera mucha confusion y que tiene que haber una tabla estado para cada tabla que lo requiera, es solo un sueño desde mi lugar de alumno.

He visto tablas donde se guardan estados horizontalmente, es decir, una columna un estado, esa tabla tenía como 30 columnas para mostrar un numero o un cero

Manuel, sobre la observación número 4, se podrían crear campos calculados en la tabla?. Al realizar el cálculo en la aplicación, se estaría amarrando una parte de la lógica de negocio (cálculos) en la aplicación, y no ayudaría al entendimiento de datos al realizar consultas sql, como por ejemplo en un sistema de planillas.

¡ Excelente aporte, Manuel ! Frecuente el error #5, es el que más he visto 😅

El error #1 es muy jodido!!! Recientemente ví esto en una BD y para trabajar con esa información es un dolor de cabeza

El 5 es un clásico de Disney

Wow que buen explicado y segmentado video tienes aquí. Lo de las llaves foraneas como me fallaba, pero he estado mejorando en ese sentido. Saludos.

hola soy novato y sin casi nada de experiencia en base de datos y bueno solo quería pedir una consulta de como hacer una relación entre unas tablas. como harías para que se relacionen lógicamente una tabla diagnóstico con una tabla expediente? y a su vez que compartan la relación con las tablas: tipo consulta, tratamiento, procedimientos y tipo procedimiento? soy nuevo en esto del desarrollo y estoy algo perdido con ello

Gracias, muy instructivo.

Que gran video. Yo creo que cualquier Dev le ha tocado pasar por al menos uno de esos errores. (Al menos verlos)

Podrías hacer un vídeo profundizando el error 4 en lo último, si necesito acceder a la información de facturas antiguas dececito saber los precios de ese entonces

Muy bueno manu. Son cosas básicas, pero pasa mucho! Gracias por compartir con ejemplos claros. Abrazoo.

Lo de eliminar un campo con un valor calculado, en una tabla con millones de registros consume mucho tiempo el calculo de los mismos por lo que conviene tener los valores guardados. Buen Video... Gracias

Tengo en cuenta esos detalles siempre, sin embargo en el caso de los estado los quemo en un array en el codigo y me ahorro un join a la hora de hacer consultas, me he tenido que enfrentar a algunos casos en que son tablas con millones de datos y un join que se ahorre uno puede reflejarse en mayor rapidez, esto lo aplico en esas relaciones uno a muchos en que la tabla solo tienen un dato como el ejemplo de estados o perfiles.

Tienes un nuevo suscriptor, me gusta tu forma de explicar y esos buenos tips deconstrucción de software, estoy chekeando tus cursos y me parece interesante el de arquitectura de software. Tengo una inquietud, ¿En que momento puedes decir como dev que eres un arquitecto de software? ¿Un titulo es necesario? Espero tu respuesta saludos.

Guardar imágenes en la Base de Datos y no la referencia de la imagen

Discrepo un poco en el punto en donde dices que no se deben de guardar valores autocalculados. Creo que eso depende del contexto. En el caso de los sistemas de facturación, cuando quieres tener toda la información, tardas más en sobre calcular los valores de los conceptos que si sólo los muestras. Ojo, eso sólo funciona cuando no se van a cambiar los datos. Es muy raro que una vez que ejecutaste una venta o una factura, modifiques los precios, para eso están los procesos de aplicación de descuentos, cancelación o devolución. Sólo mi punto de vista. Excelente video!!! :3

Bueno, Yo señalaría algunos problemas comunes: - Muy baja granularidad de mis consultas: Esto en arquitectura se podría comparar con clases a las cuales se les brinda la responsabilidad de codificar y decodificar contraseñas, pero también se le brinda la responsabilidad de escribir logs de errores. /A cada clase su responsabilidad, indica uno de los principios basicos de SOLID. El problema en las bases de datos es que esto suele representan problemas de plan de ejecución. (Divide y vencerás dice un dicho). - Tipo de indices: Las personas suelen conocer muy poco sobre que tipo de indices crear, algunos se crean físicamente atados a la tabla....y otros en un segmente separado. En bases de datos como SQLServer, Sybase, ... se suelen conoce como clustered y nonclustered. Para tablas con alta concurrencia, como una interfaz de integración, es mejor utilizar non-clustered. Y para tablas parametricas es mejor utilizar el clustered. - Tipo de bloqueo: Conocer claramente los tipos de bloqueo en la definición de tablas, por pagina, por registro, por tabla, por columna....todo depende del tipo de base de datos. En algunos casos es preferible aplicar un bloqueo por registro Ej. Tablas a las cuales accede la aplicación de forma concurrente. Puedo tener varios hilos intentando leer o escribir uno y otro registro de la misma tabla de forma simultanea, por ejemplo tablas de interface o transcicion retomando el caso anterior. - Error en uso de tablas temporales: El uso de tablas temporales puede representar una gran ventaja en temas de rendimiento (si no es excesivo), sin embargo...existe un caso temporal donde representan un problema critico para la base de datos. Y es usarlas dentro de transacciones. Posiblemente ocasionado por la anidación en la llamada de distintos procedimientos....los procedimiento externos pueden tener apertura de transacciones, y alguno de los procesos internos crear una tabla numeral...eso generar un bloqueo total de la base de datos, o el conocido abrazo mortal (o DeadLock), cuando dos procesos se encuentran simultáneamente intentando utilizar el segmento transaccional.... - Error en uso de tablas temporales2: Extraer altos volúmenes de datos sobre tablas temporales, ejemplo: Casos de reportes sobre la producción de un mes o un año...pueden colapsar la base de datos, provocando reinicio del motor de ser necesario debido a que ocupan la totalidad del segmento transaccional requerido por la base de datos, y adicional deterioro gradual del espacio transaccional asignado en corto o largo plazo... - Definición de tipos de datos, y planes de ejecución: Es muy probable que algunas consultas representen una lentitud en su ejecución, si el tipo de parametro no coincide con el definido en la tabla. Ejemplo: la llave de mi tabla es el id_parametro de tipo bigint.....y en mi proceso intento recibir un @id_parametro de tipo int, esto puede representar en algunos casos un problema en los tiempos de respuesta al ignorar el uso de indices definidos en la tabla, debido a que el tipo de dato no coincide puntualmente con el definido en la creación de la tabla. - Mal uso del Grouo By: Producto cartesiano. - Uso de Alter table: Por temas de mantenimiento no es recomendable usar alter table, es preferible renombrar el objeto (backup), redifinir la estructura de la tabla con los cambios que se desean, y posteriormente volcar los datos desde el backup a la tabla real modificada. - Lógica de negocio en procesos almacenados: creo que es el error mas común, y el dolor de cabeza de todo arquitecto de sofware. Siempre la Lógica y reglas de negocio....en el motor de reglas, o en las definiciones de la capa de negocio del aplicativo; pero nunca en la base de datos. - Uso de transacciones, en procesos de duración considerable. - Uso de tablas temporales, desde tareas de la aplicación. - Consultas en campos no indexados. - Forzar malos planes de ejecución de consultas. ....creo que es el tema de bases de datos igualmente es muy amplio!! Asi que hasta ahí....El uso de procedimientos no es una mala practica si se sabe utilizar. Un abrazo.

Hola Manuel, una pregunta, trabajo con SQL server, hay alguna forma de documentar las tablas de una forma normalizada ? un estándar en el cual yo pueda documentar el objetivo de las tablas y que se almacena en cada campo, si hay relaciones...

Sería bueno ver un vídeo con errores de bases nosql

Excelente. Estoy iniciando en esto, algún libro de referencia para aprender sobre cómo armar la base da datos para mis pequeños proyectos

hola! buen vídeo, a mi me pasa algo, y es que cuando estoy diseñando una base da datos pienso mucho en las consultas y eso hace que al final tenga una base datos cíclica, las tabas formando un circulo entre ellas, y una tabla termina conectada con muchas otras, aveces no tan exagerado, pero no se si lo este asiendo bien o hay alguna metodología para no cometer este error. Muchas gracias

Hola Manuel, muy buen video, gracias por compartir. Tengo una duda, las tablas lookup, son las tmb llamada tablas agregadas???. Y otra consulta, si tengo un modelo con datos reales, y le quiero incorporar datos proyectados para poder hacer su comparación real vs proyectado, para estos datos proyectados debo crear una tabla nueva??. Ej si quiero analizar las venta por cliente por mes --Venta Real vs Venta Proyectada, .....????. Gracias!! LM

Muchas gracias por los videos!

El error #2 era una duda que tenía gracias por aclararme eso.

buen video subscribed

Hubiera agradecido algun ejemplo concreto de indices. Pero buen video como todo lo que peoduced

Si tienes un problema de días laborales de lunes a domingo la mejor forma que encontré fue concatenándo los días en una columna 😱

Excelente Video Manuel...

Gracias por compartir tus conocimientos de esta forma Podrías hablar sobre Domain Drive Design (DDD)? No hay mucha información en español al respecto. PD:Excelente contenido!

Para el error #2, prefiero ocupar un 'enum' en el caso de C#, que guarda un int en la base de datos, así no creo una tabla.

Siempre tengo dudas de ta tabla roles crear otra tabla hacerlo, en la misma o un pivote😑

Muy buen video me encanto Manuel

Min 1:38 Para hacer lo mismo se usan las columnas tipo JSon 👍🏼

Excelente el video

Actualmente me encontré con un grupo de bases en sql server que en sus tablas no hay llaves foráneas, también realizan consultas entre bases de datos usando union all, aún no comprendo qué quisieron hacer pero lo que sí sé es que las bases están llenas de basura

Buen video, me sirve mucho para saber que errores estoy cometiendo. En el lugar donde trabajo, mi jefe no quiere utilizar llaves foráneas, algún consejo para convencerlo de utilizarlas?

Buen video!

tengo una pregunta, un error en el diseño seria emplear entidades islas, me parece que si porque no se aprovecha el concepto de las bases de datos relacionales, pero me gustaria saber que opina, Gracias!!

En el punto 2 no veo como una tabla de membresías puede evitar meter basura', al contrario ahora puedes meter el cancelada y cancelado y tienes una tabla adicional muchos a muchos para mantener...

Guardar archivos estaticos en la base de datos en lugar de usar CDN

Creo que vale la pena aclarar que esto aplica directamente a base de datos relacionales. Depende del tipo de base de datos no relacional, algunos de estos puntos también aplican

1. No crear tablas para consultas. Cuando tienes tablas con muchos joins, y quieres "mejorar el performance" del query agregar el id en las tablas para hacer menos joins Lo he visto mucho

Sobre las llaves foráneas, si las creo, como podría solucionar los problemas de migración de datos ?

Los campos que llevan números como cedula o teléfono o celular definir como tipo carácter porque no son campos que van a operarse numéricamente

¿Que libro o articulo recomienda para aprender buenas prácticas?

Para eso existen los DBA dentro de los equipos de desarrollo. Es claro que la mayoría de "errores" mencionados son novatadas que prácticamente sólo lo haría alguien que ni siquiera tenga conocimientos de al menos llevar a una tercera forma normal su DB.

no entendí lo de cancelado y cancelada porque no dejar solo cancelada ?

jajaja yo he trabajado con la BD de SAP B1 y no tiene llaves foráneas y miles de campos null

Otro sería crear una tabla "A" que tiene una FK de una tabla "B" y esta última a su vez tiene una FK que hace referencia a la tabla "A".

Buen video

Creo que aplica solamente a bases de datos relacionales

Excelente pero todos me parecieron muy básicos, si un programador comete esos errores simplemente no tiene experiencia. Gracias, la próxima tal vez abarca errores que has notado con gente experimentada

No estoy muy de acuerdo con #4, se que es una buena practica, pero en la vida real es necesario bastantes veces guardar el valor calculado, ya sea para evitar el calculo en adelante y/o optimizar los reportes ( millones de filas ).

Yo he visto uno de los más abominables y no ha sido una sola vez que lo he visto. Guardar la información en sólo 1 o 2 tablas (no normalizar)

Me tocó ver una tabla llamada calificaciones con campos llamados español, matemáticas, física, química, etc. No había manera sencilla de agregar más materias.

Eres un Mr. Miyagui....🙏

Para el error 2, ¿se pueden usar enteros en la base de datos y los valores en string trabajarlos desde el código con enums?

Buen video, la verdad es que en la vida real hay diseños de bases de datos muy malos y pues por ende la aplicación queda mal.

Osea el tipo de Json de MySQL es un error ?

al primer error se le indica como Atomico, los datos debe ser Atomicos... Al segundo se le indica llave foránea

No entiendo sobre el error 4 ,