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...
Asiento con tu comentario, en mi caso trabajo en una aseguradora donde tenemos el histórico de las pólizas por sus endosos de primas o suma, por lo tanto cada mes debemos recalcular para conocer si no existe algún cambio en el mes y posteriormente cotejar con el histórico.
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 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
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
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.
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
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.
Ya depende de las reglas de negocio, en algunos escenarios se debe guardar campos calculados, por ejemplo podría ser cuando el cálculo requiere una operación compleja que represente tiempo de procesamiento
Complementando a lo que menciona José Rodolfo, otro escenario a considerar es cuando el cálculo pueda dar distintos valores en el tiempo. Por ejemplo. el impuesto a las ventas hoy puede ser 19% pero si quisiera calcularlo de nuevo en unos años, y el impuesto ha cambiado, puede llevar a inconsistencias.
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
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.
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.
Gracias por el aporte, Alyssa! No tengo full contexto del problema, pero tu puedes tener un campo id que sea llave foránea y a la vez reciba valores nulos.
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
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.
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!.
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 🌄
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?
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.
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.
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
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.
Ahí tienes el problema de ver cosas como estatus=1, lo cual no es nada intuitivo a nivel base de datos. Visto así, no se sabe que significa cada número.
Gracias por compartir la forma en que has manejado ese caso, @jarheadmetaljacket. Has enfrentado casos donde hayas tenido que hacer un update sobre esa columna?
@@ManuelZapata entendí la referencia jejejej, si me he enfrentado y no ha habido problemas de cascade, restrict etc, pues el dato como tal siempre es el mismo, al que si me enfrentado es al impacto en tiempo por cada join
ejemplo, estado activo, inactivo, son datos que nunca voy a modificar, solo estarán eas 2 opciones si o si, o pueden haber mas pero son adicionales no que se deba modificar el dato
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.
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.
Creo que va a ser necesario hacer un video profundizando más en ese tema. Si nos pusieron estrictos con la normalización de la base de datos, deberíamos evitar estos casos al máximo. Sin embargo, creo que hay que hacer algunas precisiones.
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.
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...
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!
Ese es un tema importante, que se puede abordar de varias maneras. Aguanta un vídeo para eso. Las membresias las volví a habilitar, pero solo como un apoyo básico para el canal. Estoy viendo cómo retomarlas en 2021. Saludos!
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!
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
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
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
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
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
Amen, me tocó buscar un dato en una base de datos que tenía la manía de asignar los ID como varchar, y no podía buscar un dato ya que lo buscaba como '1' y estaba almacenado como '0001'
Pero asignar el id como varchar me parece muy acertado y lo que se debería hacer. Tu no vas a realizar operaciones con eso y en caso de empezar con 0 los perderías si no fuera varchar...
mi comentario era a un nivel más general y cuando tu aplicaciones requieren operaciones y filtros te vez obligado a realizar cast y validaciones de forma innecesaria por que se uso un varchar en lugar de fecha por ejemplo
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.
Eso lo he visto un par de veces Orion. Ante eso, yo siempre digo: A las tablas no hay que tenerles miedo. Si se necesitan, hay que crearlas. Meter datos que significan cosas diferentes en una misma tabla, termina causando problemas de acoplamiento.
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
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?
La mejor forma de convencerlo es usar una situación hipoteca, en la que por no usar las foráneas tendrán problemas más adelante. De esa manera se podrá replantear su punto de vista
Puedes indicarle que escribirán menos código de validación y les evitar perder tiempo en corregir errores de consistencia e integridad en la db. si motor de db puede evitar un problema mucho mejor.
Me paso lo mismo en un trabajo, poner las llaves tiene ventajas como integridad y consistencia de datos, seria imposible cometer algún error referenciando a una entidad (row) que no existe, también hay ventajas como eliminación en cascada, mucho software autodocumenta tu base de datos con modelos de entidad relación únicamente inspeccionando tu db(si tienes las fk). Pero el mas importante es el de integridad de datos desde mi punto de vista.
Muchas gracias a todos por sus respuestas, sinceramente no sé su razón exacta por la cual no le gusta y/o no quiere utilizar llaves foráneas, pero con sus sugerencias le plantearé una situación y espero tenga éxito 😁
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.
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
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!!
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!
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
La base de datos es otro nivel de abstracción. Deberías pensar que esa base de datos en un futuro podría ser consultada por otra aplicación. Así que es mejor que la base de datos sea lo más autónoma posible.
Gracias por el aporte! Yo suelo tener tanto la enum en código como la tabla en base de datos. Tener solo el enum te facilita el código en C#, pero no elimina el problema de integridad referencial.
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...
El punto es ya no puedes crear directamente un registro en la tabla de membresias sin que exista en la tabla de estados. Eso te ayuda a garantizar la integridad referencial
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
Buena pregunta, Jesus. Yo no sacrificaría la integridad de los datos por una migración. Preferiría hacer código de migración y transformar esos datos a lo que mi modelo necesita.
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 ).
Estoy de acuerdo, el punto número 4 solo lo aplicó cuando los valores calculados cambian constantemente pues requerirían muchas operaciones de lectura y escritura. Ejemplo de dónde lo aplicó: la existencia de productos en un almacén, en donde no: el monto total de una venta.
A mi me gusta pensar en el caso #4 como una excepción, más no la regla. Es decir, si empiezo a encontrarme problemas de rendimiento, ver como se puede optimizar.
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
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.
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.
Hay empresas que no tienen dba. Por lo general, esas malas parcticas no generan problemas al inicio, pero mientras la empresa crece, estos problemas son muy graves y costosos de erradicar.
Porque lo he visto muchas veces, fue que me animé a hacer el video. Es claro que son novatadas, pero desafortunadamente ocurren. Así existan DBAs en un equipo de desarrollo, considero un conocimiento importante para un desarrollador saber normalizar (al menos 3FN como dices).
Yo creo que ese escenario es diferente. Si entiendo bien, SAP debe proveer un modelo de datos genérico que soporte las personalizaciones de cada cliente, entonces allí puede tener sentido contar la menor cantidad posible de restricciones.
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
Gracias por el aporte Renso! Si ocurre el #4, está fatal. Y el #10 es una práctica que parece obvia, pero en la que se suele fallar.
crear backups de la db!! Dios! este debería ser el más importante!! jaja
8.??
@@neoclassicaltechno debería ser delito no hacerlo
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...
Asiento con tu comentario, en mi caso trabajo en una aseguradora donde tenemos el histórico de las pólizas por sus endosos de primas o suma, por lo tanto cada mes debemos recalcular para conocer si no existe algún cambio en el mes y posteriormente cotejar con el histórico.
Podrías hacer uno sobre errores en las consultas? y consejos. y excelente video, gracias
Excelente video Bro. muchas gracias, muy buen material.
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 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
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
Excelente explicación. Gracias!
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.
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
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.
Ya depende de las reglas de negocio, en algunos escenarios se debe guardar campos calculados, por ejemplo podría ser cuando el cálculo requiere una operación compleja que represente tiempo de procesamiento
Complementando a lo que menciona José Rodolfo, otro escenario a considerar es cuando el cálculo pueda dar distintos valores en el tiempo. Por ejemplo. el impuesto a las ventas hoy puede ser 19% pero si quisiera calcularlo de nuevo en unos años, y el impuesto ha cambiado, puede llevar a inconsistencias.
También si necesitas buscar por el monto total. Es necesario guardarlo (procesar el cálculo cada vez, consume recursos)
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
Gracias por el aporte, Peter!
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.
Muy buen aporte Mauricio. Gracias!
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.
Gracias por el aporte, Alyssa! No tengo full contexto del problema, pero tu puedes tener un campo id que sea llave foránea y a la vez reciba valores nulos.
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
Gracias, muy instructivo.
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.
Genial Leo! 🙌
Gracias tío , me subes el autoestima en ocasiones tengo que discutir con pttomadores que diseñaron horrible sus base de datos
Muy valiosa tu experiencia, muchas gracias. Saludos desde Argentina
Saludos Adrián. Gracias!
Gracias por la guía, muy útil para tener en cuenta al momento de diseñar nuestras bases de datos.
Con todo gusto, Brian!
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.
Genial Alex. La idea es esa: ir mejorando poco a poco.
ALELUYA, NO ESTOY LOCO!!!! NO ESTOY SOLO!!!! Hay más gente a la que le sangran los ojos cuando ven esas cosas T^T
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!.
Gracias por el aporte, Claudio. Saludos!
Que buen video, este tema de BD es algo muy interesante, si puedes seguir teniendo info de esta será muy chevere
Gracias por la sugerencia, Camilo. Lo tendré muy en cuenta.
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 video me ayudó mucho
Excelente video! Gracias por compartir 🙂 También es cierto que con la ayuda de los frameworks estamos menos expuestos a ciertos errores
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 🌄
Gracias por el video Manuel, siempre con buenos aportes.
Gracias Binomino!
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?
Esa es una buena pregunta. Ya la anoté para un futuro video.
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.
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.
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
Excelente video!
Podrías hacer uno de base de datos no relacionales?
Lo anoto en la lista de videos. Gracias por la recomendación!
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.
Ahí tienes el problema de ver cosas como estatus=1, lo cual no es nada intuitivo a nivel base de datos. Visto así, no se sabe que significa cada número.
@@yomero4427 no uso estaus, solo le metos status= activo, inactivo, sin numeros, asi mismo en las cosultas y sale pa pintura
Gracias por compartir la forma en que has manejado ese caso, @jarheadmetaljacket. Has enfrentado casos donde hayas tenido que hacer un update sobre esa columna?
@@ManuelZapata entendí la referencia jejejej, si me he enfrentado y no ha habido problemas de cascade, restrict etc, pues el dato como tal siempre es el mismo, al que si me enfrentado es al impacto en tiempo por cada join
ejemplo, estado activo, inactivo, son datos que nunca voy a modificar, solo estarán eas 2 opciones si o si, o pueden haber mas pero son adicionales no que se deba modificar el dato
Muy bueno manu. Son cosas básicas, pero pasa mucho! Gracias por compartir con ejemplos claros. Abrazoo.
Con gusto Fernando! Así es. Son cosas básicas, pero siguen ocurriendo.
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.
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.
Creo que va a ser necesario hacer un video profundizando más en ese tema. Si nos pusieron estrictos con la normalización de la base de datos, deberíamos evitar estos casos al máximo. Sin embargo, creo que hay que hacer algunas precisiones.
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.
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...
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!
Tablas temporales
Particionamiento
Ese es un tema importante, que se puede abordar de varias maneras. Aguanta un vídeo para eso.
Las membresias las volví a habilitar, pero solo como un apoyo básico para el canal. Estoy viendo cómo retomarlas en 2021. Saludos!
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!
Que gran video. Yo creo que cualquier Dev le ha tocado pasar por al menos uno de esos errores. (Al menos verlos)
Así es, Carlos. De que pasan, pasan. Saludos!
Excelente video. Sería interesante también hacer este análisis a las bases de datos no sql. Saludos.
Ya lo tengo en la lista de videos. Gracias por la sugerencia Luis.
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
¡ Excelente aporte, Manuel ! Frecuente el error #5, es el que más he visto 😅
Pasa, pasa. Saludos Oscar!
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
Gracias por el aporte Christian. Yo creo que eso depende mucho de la complejidad del cálculo.
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
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
Rodrigo, la verdad es que no tengo ningún material de referencia. Pero hay bastante contenido en línea al respecto.
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
Gracias por el aporte Renso!
Por comentarios como este me ahorre el vídeo completo, gracias!
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
yo agregaría varchar para todos los campos sin importa el contenido.
Ufff esa es una común.
Amen, me tocó buscar un dato en una base de datos que tenía la manía de asignar los ID como varchar, y no podía buscar un dato ya que lo buscaba como '1' y estaba almacenado como '0001'
Pero asignar el id como varchar me parece muy acertado y lo que se debería hacer. Tu no vas a realizar operaciones con eso y en caso de empezar con 0 los perderías si no fuera varchar...
mi comentario era a un nivel más general y cuando tu aplicaciones requieren operaciones y filtros te vez obligado a realizar cast y validaciones de forma innecesaria por que se uso un varchar en lugar de fecha por ejemplo
para el uso de fechas y horas es mejor Varchar que Timestamp?
Saludos desde Brasil
Sería bueno ver un vídeo con errores de bases nosql
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.
Eso lo he visto un par de veces Orion. Ante eso, yo siempre digo: A las tablas no hay que tenerles miedo. Si se necesitan, hay que crearlas. Meter datos que significan cosas diferentes en una misma tabla, termina causando problemas de acoplamiento.
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
Tocas un punto importante. Gracias por el aporte, Jesús!
@@ManuelZapata Muchas gracias
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.
El error #2 era una duda que tenía gracias por aclararme eso.
Con gusto Alonso!
Muchas gracias por los videos!
Con gusto Alejandro!
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?
La mejor forma de convencerlo es usar una situación hipoteca, en la que por no usar las foráneas tendrán problemas más adelante. De esa manera se podrá replantear su punto de vista
Puedes indicarle que escribirán menos código de validación y les evitar perder tiempo en corregir errores de consistencia e integridad en la db. si motor de db puede evitar un problema mucho mejor.
Me paso lo mismo en un trabajo, poner las llaves tiene ventajas como integridad y consistencia de datos, seria imposible cometer algún error referenciando a una entidad (row) que no existe, también hay ventajas como eliminación en cascada, mucho software autodocumenta tu base de datos con modelos de entidad relación únicamente inspeccionando tu db(si tienes las fk). Pero el mas importante es el de integridad de datos desde mi punto de vista.
Creo que todos te acaban de dar muy buenas sugerencias, Kevin! Solo por curiosidad, por qué tu jefe no quiere usarlas?
Muchas gracias a todos por sus respuestas, sinceramente no sé su razón exacta por la cual no le gusta y/o no quiere utilizar llaves foráneas, pero con sus sugerencias le plantearé una situación y espero tenga éxito 😁
Min 1:38 Para hacer lo mismo se usan las columnas tipo JSon 👍🏼
El error #1 es muy jodido!!! Recientemente ví esto en una BD y para trabajar con esa información es un dolor de cabeza
Excelente Video Manuel...
Gracias Andres! 🙌
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.
El 5 es un clásico de Disney
pasa, y hay personas que los defienden. No entiendo porque.
Muy buen video me encanto Manuel
Yo creo que lo que más ayuda es estudiar teoría de bases de datos y las distintas formas normales.
Excelente el video
Gracias John!
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
Así es, bases de datos relaciones.
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!!
Yo creo qque el normal tener algunas tablas isla. Lo que si no debería pasar es que sean demasiadas. Creo que eso ya implicaría un problema de diseño.
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!
Ese es uno de las grandes temas pendientes del canal, William. Seguro en 2021 haré algunos vídeos al respecto.
@@ManuelZapata Excelente, lo esperaré con muchas ansias!
¿Que libro o articulo recomienda para aprender buenas prácticas?
Estudia la teoría de bases de datos y las formas normales. Eso te elimina muchas malas prácticas.
@@ManuelZapata Muchas gracias
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 😱
Buen video!
Gracias Bladimir 🙌
Hubiera agradecido algun ejemplo concreto de indices. Pero buen video como todo lo que peoduced
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
Sin llaves foráneas, a eso queda expuesta la base de datos.
@@ManuelZapata que estrategia me recomiendas para comenzar a colocar llaves foráneas en las tablas?
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.
La base de datos es otro nivel de abstracción. Deberías pensar que esa base de datos en un futuro podría ser consultada por otra aplicación. Así que es mejor que la base de datos sea lo más autónoma posible.
Gracias por el aporte! Yo suelo tener tanto la enum en código como la tabla en base de datos.
Tener solo el enum te facilita el código en C#, pero no elimina el problema de integridad referencial.
Guardar imágenes en la Base de Datos y no la referencia de la imagen
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...
El punto es ya no puedes crear directamente un registro en la tabla de membresias sin que exista en la tabla de estados. Eso te ayuda a garantizar la integridad referencial
@@ManuelZapata el punto era evitar basura... y un usuario dispuesto siempre creará basura...así que la solución no es útil para el fin que puso
Ahora en lugar de una tabla con basura... tienes 2
buen video
subscribed
Bienvenido!
Siempre tengo dudas de ta tabla roles crear otra tabla hacerlo, en la misma o un pivote😑
Yo los separe en una relación muchos a muchos, pero a la hora de hacer un select tenés que hacer Joins y no sé siento que no está muy bien
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
Esa es una peligrosa. Tener esa redundancia te lleva a hacer actualizaciones en múltiples lados.
Guardar archivos estaticos en la base de datos en lugar de usar CDN
Sobre las llaves foráneas, si las creo, como podría solucionar los problemas de migración de datos ?
Buena pregunta, Jesus. Yo no sacrificaría la integridad de los datos por una migración. Preferiría hacer código de migración y transformar esos datos a lo que mi modelo necesita.
Buen video
Gracias!
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 ).
Estoy de acuerdo, el punto número 4 solo lo aplicó cuando los valores calculados cambian constantemente pues requerirían muchas operaciones de lectura y escritura.
Ejemplo de dónde lo aplicó: la existencia de productos en un almacén, en donde no: el monto total de una venta.
A mi me gusta pensar en el caso #4 como una excepción, más no la regla. Es decir, si empiezo a encontrarme problemas de rendimiento, ver como se puede optimizar.
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".
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
no entendí lo de cancelado y cancelada porque no dejar solo cancelada ?
Claro, deberías tener un solo estado. El problema es que como tienes un varchar y no hay nada que restrinja, ambas cadenas podrían guardarse.
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
El problema es que son “básicos”, y aun así se siguen repitiendo. Qué error de gente experimentada añadirías a la lista?
Creo que aplica solamente a bases de datos relacionales
Sí, está orientado a bases de datos relacionales.
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.
Un excelente ejemplo cuando no se tiene claro cómo normalizar!!
Eres un Mr. Miyagui....🙏
Gracias por esas palabras. No creo que sea así, pero se hace lo mejor posible.
Osea el tipo de Json de MySQL es un error ?
Adicional el tener muchas columnas incrementan el tamaño de la base de datos
No digo que sea un error. Solo decía que no lo incluía en los casos que menciono en el error 1.
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.
Hay empresas que no tienen dba. Por lo general, esas malas parcticas no generan problemas al inicio, pero mientras la empresa crece, estos problemas son muy graves y costosos de erradicar.
Porque lo he visto muchas veces, fue que me animé a hacer el video. Es claro que son novatadas, pero desafortunadamente ocurren. Así existan DBAs en un equipo de desarrollo, considero un conocimiento importante para un desarrollador saber normalizar (al menos 3FN como dices).
al primer error se le indica como Atomico, los datos debe ser Atomicos...
Al segundo se le indica llave foránea
Gracias por el aporte, Darwin!
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.
Así es Carlos! Si la BD de datos arranca mal, de ahí para arriba todo se complica.
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)
jajaja yo he trabajado con la BD de SAP B1 y no tiene llaves foráneas y miles de campos null
Yo creo que ese escenario es diferente. Si entiendo bien, SAP debe proveer un modelo de datos genérico que soporte las personalizaciones de cada cliente, entonces allí puede tener sentido contar la menor cantidad posible de restricciones.
imagina pedir 20 millones de calculos para sumar en vez de seleccionar el campo total