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
@ManuelZapata3 жыл бұрын
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.
@metronomo16762 жыл бұрын
crear backups de la db!! Dios! este debería ser el más importante!! jaja
@defaultName-gw1vg2 жыл бұрын
8.??
@richarcenteno5821 Жыл бұрын
@@metronomo1676 debería ser delito no hacerlo
@luigi.escalante3 жыл бұрын
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...
@josedonaldolunaguardado51199 ай бұрын
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.
@azaelmtz93933 жыл бұрын
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
@javiergavilanmerida21333 жыл бұрын
ALELUYA, NO ESTOY LOCO!!!! NO ESTOY SOLO!!!! Hay más gente a la que le sangran los ojos cuando ven esas cosas T^T
@roberthjsb3 жыл бұрын
yo agregaría varchar para todos los campos sin importa el contenido.
@ManuelZapata3 жыл бұрын
Ufff esa es una común.
@maximilianocamilo65563 жыл бұрын
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'
@-ajrego-48693 жыл бұрын
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...
@roberthjsb3 жыл бұрын
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
@alianzatroll3 жыл бұрын
para el uso de fechas y horas es mejor Varchar que Timestamp?
@ZornLeMa3 жыл бұрын
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.
@joserodolfoluisataxicevall95453 жыл бұрын
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
@ManuelZapata3 жыл бұрын
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.
@rai_743 жыл бұрын
También si necesitas buscar por el monto total. Es necesario guardarlo (procesar el cálculo cada vez, consume recursos)
@transformers8862 жыл бұрын
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
@YouFrienD1323 жыл бұрын
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!
@mirxtremapps2 жыл бұрын
Podrías hacer uno sobre errores en las consultas? y consejos. y excelente video, gracias
@nelson33912 жыл бұрын
Excelente explicación. Gracias!
@FrankJaimeFabianPuente-sy1yr3 жыл бұрын
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
@FranciscoFerreiradelaCruz3 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Gracias por el aporte, Peter!
@mgbeltranb3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Muy buen aporte Mauricio. Gracias!
@Aprendder3 жыл бұрын
Que buen video, este tema de BD es algo muy interesante, si puedes seguir teniendo info de esta será muy chevere
@ManuelZapata3 жыл бұрын
Gracias por la sugerencia, Camilo. Lo tendré muy en cuenta.
@maximilianominetto5243 жыл бұрын
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!
@ctj013 жыл бұрын
Tablas temporales
@joserodolfoluisataxicevall95453 жыл бұрын
Particionamiento
@ManuelZapata3 жыл бұрын
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!
@metronomo16762 жыл бұрын
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.
@hdeleonnet3 жыл бұрын
El 5 es un clásico de Disney
@ManuelZapata3 жыл бұрын
pasa, y hay personas que los defienden. No entiendo porque.
@lvbernal3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Genial Leo! 🙌
@maf_k48102 жыл бұрын
Buen video me ayudó mucho
@MarcosHernandez_VE2 жыл бұрын
Excelente video Bro. muchas gracias, muy buen material.
@pablogonzalezrobles44292 жыл бұрын
Sería bueno ver un vídeo con errores de bases nosql
@stefanypatrick953 жыл бұрын
Gracias tío , me subes el autoestima en ocasiones tengo que discutir con pttomadores que diseñaron horrible sus base de datos
@UskoKruM20103 жыл бұрын
¡ Excelente aporte, Manuel ! Frecuente el error #5, es el que más he visto 😅
@ManuelZapata3 жыл бұрын
Pasa, pasa. Saludos Oscar!
@carlosbenavides63543 жыл бұрын
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!
@getrece_3 жыл бұрын
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.
@LuisChang3 жыл бұрын
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.
@piratamorgan29983 жыл бұрын
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 🌄
@25Sunburst2 жыл бұрын
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
@Renso20103 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Gracias por el aporte Renso!
@cifz3 жыл бұрын
Por comentarios como este me ahorre el vídeo completo, gracias!
@wineloy3 жыл бұрын
El error #1 es muy jodido!!! Recientemente ví esto en una BD y para trabajar con esa información es un dolor de cabeza
@alyssabuensuceso37333 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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.
@cegottardi9 ай бұрын
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.
@VanderleiRobertoMoretto3 жыл бұрын
Saludos desde Brasil
@AdrianFernandezFazio3 жыл бұрын
Muy valiosa tu experiencia, muchas gracias. Saludos desde Argentina
@ManuelZapata3 жыл бұрын
Saludos Adrián. Gracias!
@alexvalle9973 жыл бұрын
Excelente video! Podrías hacer uno de base de datos no relacionales?
@ManuelZapata3 жыл бұрын
Lo anoto en la lista de videos. Gracias por la recomendación!
@Colmedoherman3 жыл бұрын
Excelente video! Gracias por compartir 🙂 También es cierto que con la ayuda de los frameworks estamos menos expuestos a ciertos errores
@pabloartero11553 жыл бұрын
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?
@ManuelZapata3 жыл бұрын
Esa es una buena pregunta. Ya la anoté para un futuro video.
@ehm12243 жыл бұрын
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.
@AlexAcostaB3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Genial Alex. La idea es esa: ir mejorando poco a poco.
@briancardona3443 жыл бұрын
Gracias por la guía, muy útil para tener en cuenta al momento de diseñar nuestras bases de datos.
@ManuelZapata3 жыл бұрын
Con todo gusto, Brian!
@caralrahe13 жыл бұрын
Que gran video. Yo creo que cualquier Dev le ha tocado pasar por al menos uno de esos errores. (Al menos verlos)
@ManuelZapata3 жыл бұрын
Así es, Carlos. De que pasan, pasan. Saludos!
@binomio88703 жыл бұрын
Gracias por el video Manuel, siempre con buenos aportes.
@ManuelZapata3 жыл бұрын
Gracias Binomino!
@legui4445323 жыл бұрын
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
@itmarck3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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.
@claudiomnec3 жыл бұрын
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!.
@ManuelZapata3 жыл бұрын
Gracias por el aporte, Claudio. Saludos!
@jimtl11152 жыл бұрын
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
@cesaraugusto663 жыл бұрын
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.
@ciefsapien97283 жыл бұрын
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
@sebastiandelrio31353 жыл бұрын
Guardar imágenes en la Base de Datos y no la referencia de la imagen
@Unknown9713 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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.
@user-zr6dn2bo8g9 ай бұрын
Hubiera agradecido algun ejemplo concreto de indices. Pero buen video como todo lo que peoduced
@alfirian3 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Tocas un punto importante. Gracias por el aporte, Jesús!
@alfirian3 жыл бұрын
@@ManuelZapata Muchas gracias
@fernandoacosta85813 жыл бұрын
Muy bueno manu. Son cosas básicas, pero pasa mucho! Gracias por compartir con ejemplos claros. Abrazoo.
@ManuelZapata3 жыл бұрын
Con gusto Fernando! Así es. Son cosas básicas, pero siguen ocurriendo.
@eduardojosegarcia2583 жыл бұрын
Gracias, muy instructivo.
@xtobctbm3 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Gracias por el aporte Christian. Yo creo que eso depende mucho de la complejidad del cálculo.
@alonso44363 жыл бұрын
El error #2 era una duda que tenía gracias por aclararme eso.
@ManuelZapata3 жыл бұрын
Con gusto Alonso!
@krashdata3 жыл бұрын
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.
@jarheadmetaljacket3 жыл бұрын
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.
@yomero44273 жыл бұрын
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.
@jarheadmetaljacket3 жыл бұрын
@@yomero4427 no uso estaus, solo le metos status= activo, inactivo, sin numeros, asi mismo en las cosultas y sale pa pintura
@ManuelZapata3 жыл бұрын
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?
@jarheadmetaljacket3 жыл бұрын
@@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
@jarheadmetaljacket3 жыл бұрын
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
@fernandopoveda54853 жыл бұрын
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.
@rodrigovalladares68163 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Rodrigo, la verdad es que no tengo ningún material de referencia. Pero hay bastante contenido en línea al respecto.
@josuegonzalez33243 жыл бұрын
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 😱
@michaelalexischaconmarin91643 жыл бұрын
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
@miguelangelquinteroportill97463 жыл бұрын
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...
@johnfriend20103 жыл бұрын
buen video subscribed
@ManuelZapata3 жыл бұрын
Bienvenido!
@lorenamairano59593 жыл бұрын
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
@alfredrodriguezgarcia23833 жыл бұрын
Siempre tengo dudas de ta tabla roles crear otra tabla hacerlo, en la misma o un pivote😑
@santiago47733 жыл бұрын
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
@TufikChediak3 жыл бұрын
Guardar archivos estaticos en la base de datos en lugar de usar CDN
@Keiktu3 жыл бұрын
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.
@texcanarias3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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.
@williand.5293 жыл бұрын
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!
@ManuelZapata3 жыл бұрын
Ese es uno de las grandes temas pendientes del canal, William. Seguro en 2021 haré algunos vídeos al respecto.
@williand.5293 жыл бұрын
@@ManuelZapata Excelente, lo esperaré con muchas ansias!
@ulisestlahuizo71013 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Sin llaves foráneas, a eso queda expuesta la base de datos.
@ulisestlahuizo71013 жыл бұрын
@@ManuelZapata que estrategia me recomiendas para comenzar a colocar llaves foráneas en las tablas?
@AlejandroFernandez-jx4oo3 жыл бұрын
Muchas gracias por los videos!
@ManuelZapata3 жыл бұрын
Con gusto Alejandro!
@javobqcol3 жыл бұрын
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...
@ManuelZapata3 жыл бұрын
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
@javobqcol3 жыл бұрын
@@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
@javobqcol3 жыл бұрын
Ahora en lugar de una tabla con basura... tienes 2
@blackc70143 жыл бұрын
Muy buen video me encanto Manuel
@ManuelZapata3 жыл бұрын
Yo creo que lo que más ayuda es estudiar teoría de bases de datos y las distintas formas normales.
@andresorozcoj.88763 жыл бұрын
Excelente Video Manuel...
@ManuelZapata3 жыл бұрын
Gracias Andres! 🙌
@oscarmarin46383 жыл бұрын
Min 1:38 Para hacer lo mismo se usan las columnas tipo JSon 👍🏼
@gardtec28733 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Así es, bases de datos relaciones.
@josetovarrodriguez35253 жыл бұрын
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!!
@ManuelZapata3 жыл бұрын
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.
@johncerpa37823 жыл бұрын
Excelente el video
@ManuelZapata3 жыл бұрын
Gracias John!
@rumpelstiltskin083 жыл бұрын
Sobre las llaves foráneas, si las creo, como podría solucionar los problemas de migración de datos ?
@ManuelZapata3 жыл бұрын
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.
@kevinacosta13213 жыл бұрын
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?
@danielgiraldo36773 жыл бұрын
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
@grillingo3 жыл бұрын
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.
@alex18019213 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Creo que todos te acaban de dar muy buenas sugerencias, Kevin! Solo por curiosidad, por qué tu jefe no quiere usarlas?
@kevinacosta13213 жыл бұрын
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 😁
@cesaraugustoguerreromateus29013 жыл бұрын
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
@blado90593 жыл бұрын
Buen video!
@ManuelZapata3 жыл бұрын
Gracias Bladimir 🙌
@xzdasx3 жыл бұрын
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
@ManuelZapata3 жыл бұрын
Esa es una peligrosa. Tener esa redundancia te lleva a hacer actualizaciones en múltiples lados.
@cesarrojas90403 жыл бұрын
no entendí lo de cancelado y cancelada porque no dejar solo cancelada ?
@ManuelZapata3 жыл бұрын
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.
@computerman2k73 жыл бұрын
Creo que aplica solamente a bases de datos relacionales
@ManuelZapata3 жыл бұрын
Sí, está orientado a bases de datos relacionales.
@JoseGonzalez-qs5wz3 жыл бұрын
¿Que libro o articulo recomienda para aprender buenas prácticas?
@ManuelZapata3 жыл бұрын
Estudia la teoría de bases de datos y las formas normales. Eso te elimina muchas malas prácticas.
@JoseGonzalez-qs5wz3 жыл бұрын
@@ManuelZapata Muchas gracias
@jesusalbertocastillo4708 Жыл бұрын
jajaja yo he trabajado con la BD de SAP B1 y no tiene llaves foráneas y miles de campos null
@ManuelZapata Жыл бұрын
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.
@yomero44273 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Un excelente ejemplo cuando no se tiene claro cómo normalizar!!
@MiguelReyesDeveloper3 жыл бұрын
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".
@defaultName-gw1vg2 жыл бұрын
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
@ManuelZapata2 жыл бұрын
El problema es que son “básicos”, y aun así se siguen repitiendo. Qué error de gente experimentada añadirías a la lista?
@grillingo3 жыл бұрын
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 ).
@ElixCastillo3 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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.
@julioalejandrosantoscorona54803 жыл бұрын
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)
@oswaldocalderon95353 жыл бұрын
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.
@yomero44273 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
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).
@0scarDev3 жыл бұрын
Buen video
@ManuelZapata3 жыл бұрын
Gracias!
@wiltonvp29043 жыл бұрын
Eres un Mr. Miyagui....🙏
@ManuelZapata3 жыл бұрын
Gracias por esas palabras. No creo que sea así, pero se hace lo mejor posible.
@pringstom Жыл бұрын
imagina pedir 20 millones de calculos para sumar en vez de seleccionar el campo total
@johnpazherrera45533 жыл бұрын
No entiendo sobre el error 4 ,
@ManuelZapata3 жыл бұрын
Se trata de tener cuidado al guardar información que puede ser calculable. Si no se hace de manera apropiada, puede llevar a inconsistencias en los datos.
@itmarck3 жыл бұрын
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?
@ManuelZapata3 жыл бұрын
Yo lo he manejado así en varias ocasiones, Marcelo. Usar enums en este caso le da mucha legibilidad al código.
@leo123juan3 жыл бұрын
Osea el tipo de Json de MySQL es un error ?
@leo123juan3 жыл бұрын
Adicional el tener muchas columnas incrementan el tamaño de la base de datos
@ManuelZapata3 жыл бұрын
No digo que sea un error. Solo decía que no lo incluía en los casos que menciono en el error 1.
@carlosestebanguzmanbaquero21393 жыл бұрын
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.
@ManuelZapata3 жыл бұрын
Así es Carlos! Si la BD de datos arranca mal, de ahí para arriba todo se complica.