Una FK ademas de relacionar las tablas ayuda al programador nuevo entender la relacion entre ellas, me explico el developer que sabe del negocio un dia X se va, se enferma, le ocurre algo, luego otro toma su lugar y no sabe del negocio las FK ayudan bastante a relacionar tablas y saber donde tocar y que manipular.
@@christianalvarezsanchez8583 pues en mi experiencia las bases de datos son poco documentadas, el código no tiene nada que ver con una base de datos porque usan modelos diferentes por esos existen los ORM.
Completamente de acuerdo. Yo entré a mi primer trabajo en una startup en la que había un único "desarrollador" PHP WordPress. De PHP ni él sabía qué era una clase. Cuando le pregunté sobre cosas de WordPress, porque no sabía, me contó un popurrí de cosas que no entendí nada. Abrí el DBeaver, vi el esquema de entidades, y al toque entendí cómo funcionaba todo. Desde ese momento pude empezar a desarrollar.
Iba a decir algo parecido a lo que dijiste... Si vas a quitar algo propio de una base de datos relacional, pues lo mejor sería no utilizar la relacional sino las otras opciones... pero ya decir que no tiene sentido como el del tweet... pues... se queda corto!!!
Las FK tienen su razón de ser... incluso para alguien nuevo que toma tu modelo de DB (sin diccionario de datos y sin nada más) para al menos entender la lógica/integridad de lo que has intentado hacer. No acepto que no las haya aun cuando sea un modelo básico de DB.
👍 por favor Sr. De Leon una explicación para esos casos donde la información es grande tanto para la persistencia y la lectura de los mismos, aprender tecnicas para las queries
Apoyo el proximo video de alternativas a bases de datos relacionales y si se puede ser sobre alternativas open source mejor. Gracias Héctor por las reflexiones. Saludos a la comunidad!!
Buenas!! Muy informativo y claro como siempre!! Estaría bueno así un mini curso o algo enseñando a como trabajar con sql y no-sql a la vez y como mencionas en el video, cuando es conveniente una implementación de ese tipo. Gracias por subir toda esta enseñanza, siempre me sacan de algún lio 😅
Tecnicamente: cuando se agrega un FK se crea un contraint index, el cual se utilizara p validad la integridad. En varias Lectures de grandes empresas observaran que eliminaron los FK y utilizan la mezcla de bases de datos relacionales y NO relacionales por escalabilidad.
No soy experto, pero justo esto es a lo que se debió referir el tipo del tweet. Una cosa es la llave y otra el constraint. Se puede tener la llave sin el constraint
En las empresas donde he trabajado no he necesitado eliminar FKs o usar nosql, las tablas que he manejado tienen algunos pocos millones y aunque si he enfrentado problemas de rendimiento no han sido causadas por las FK's sino por la arquitectura del frontend pero ese es otro tema...
Solo alguien que no sepa DB relacionales diría algo así, de cualquier forma el DBA debe diseñar un buen modelo de base de datos y protegerlos de las fallas de lógica en las aplicaciones.
eyyyyyyyy excelente este video, excelente iluminación... felicitaciones, excelente ver este video con buena luz, ahí le deje el pulgarcito arriba, saludos
Justo pensé en las BD NoSQL, eso es básico del diseño y modelado de DB que antes de crear la DB debes pensar en que tipo de información vas guardar, si necesitas un orden estricto o mas flexible. Estaría genial ver mas estrategias.
Tenes que hacer un video sobre composite Keys y sus problemas cuando el projecto escala, y los composite keys pueden pasar de ser solo 2 a 3 y a veces hasta 4, y lo que implica con el resto de las relaciones hacia esa tabla. Luego podrías hablar del concepto historization y tablas Master e History, y de cuáles son las ventajas del 1:1 vs el n:1. Son temas con los que los programadores se encuentran tarde o temprano y tienen que optar por una solución.
También puedes utilizar projections, creas una tabla única con todas las columnas necesarias, perp esta projection debe ser rellenada a partir de una query que consulte todos los datos que se necesitan de una DDBB relacional con FKs
desde tu ejemplo cuando 1 referencia dentro de la tabla A hacia 1millon de la tabla B, Una estrategia podria ser crear 1 tabla C que sea que agrupe por zonas y con eso la base de datos seria menos estresada y conservando las Fk
Las FK ayudan a no repetir datos, reducen la cantidad de espacio requerido para almacenar la información, sirven como indices, y para los inserts no ralentizan tanto ya que exiten busquedas binarias en los índices. Se pueden desactivar cuando cargas datos masivos y sabes que los datos son integros y las activas una ves cargados, pero esa es tarea del DBA.
Hasta donde tengo entendido las FK a parte de dar integridad a los datos, estas generan un índice para hacer la búsquedas más rápidas y no tener problemas a la hora buscar información, no es correcto mencionar NoSQL cuando no está hecho para leer tanta información. Si no los bancos y grandes empresas tendría. Su data en estos tipos de BD. El tweet tal vez está enfocado a otro tipo de problemas que no es relacionado a esto, si no tienes bien hecha tu BD tendrás problemas de este tipo, muchas veces me tocó corregir consultas a la BD por qué no las hacían bien, ojo no soy DBA Saludos cordiales
Héctor, a ver, si eliminas la foreing key y dejas que el backend maneje la integridad en la aplicación, el backend no tiene que hacer los mismo que SQL? Buscar en las 10M de marcas para ver si existe? Digo...
Que las fk son una carga? Que conviene usar NoSQL cuando hay más de 10 MM de registros? Bullshit! En big data se siguen utilizando fk sin ningún problema, en sistemas distribuídos modernos de datawarehouse las fk son básicas en el modelado multidimensional. La optimización de los tiempos de consulta se maneja por otras vías pero nunca, y repito NUNCA, eliminando las fk. El que posteó la eliminación de las fk no tiene mucha idea de como se maneja el tuning de bases de datos cuando se trabaja con big data.
¿Cuáles son esas alternativas?, porque no conozco tan a profundidad los motores sql, así sin investigar lo único que se me ocurre es tener una tabla intermedia que no use fk e irlas pasando poco a poco, pero seria mucho lio.
Puedes crear indices para campos por los que filtres frecuentemente en tus queries, puedes crear vistas materializadas para consultas o subconsultas complejas y/o frecuentes, puedes usar una base de datos distribuida para tener procesamiento y distribucion paralela de los datos y ajustar el particionamiento como la distribucion del cluster de nodos que conforman esa base de datos@@MinombreesSergio
Excelente video, esto es síntoma de usar siempre NoSQL y no tener [Ni p...] idea de DBs relacionales y como hacer una correcta normalización de las tablas, campos e índices, con esto ultimo se puede evitar o disminuir el caso explicado en el video.
dependiendo bro, en muchas soluciones no es necesario, por eso están las Nosql y entre otras porque en muchas ocaciones puedes manejarlo desde el código y la base de datos cuando las reglas de negocio son muy cambiantes solo necesitas donde persistir la data de forma lógica.
@@christianalvarezsanchez8583 No es una cuestión de necesidad, en algunos casos puede ser más conveniente utilizar una base de datos relacional y en otros no, depende mucho del contexto concreto del problema que se quiera modelar. Si va a trabajar con grandes volúmenes de datos y las relaciones entre las entidades no son tan marcadas, NoSql podría ser una excelente opción como bien lo explicó Héctor en el video, en caso contrario una base de datos relacional sería una una buena solución. En este mundo no hay blancos o negros, existen matices que no se deben pasar por alto.
@@christianalvarezsanchez8583 Obvio que NoSQL tiene sus aplicaciones, solo que en este caso, decir tal aberración sobre la FK, es un claro indicio de ignorancia supina.
@@GabrielGonzalez-kd9hf Bro en el desarrollo de software hay muchas formas de llegar a la solución, he visto empresas con grandes cantidades de tráfico que no usan fks y trabajan muy bien y escalan bien.
Me pregunto si cachear los datos de la tabla que contiene las FK sea una buena opción. y que la cache se pueda refrescar si hay un nuevo registro en esa tabla, de esta manera la validación de la integridad en la lógica podría ser más rápida. Es una idea jejeje. Pero sí sería bueno que nos regalaras un video explicando como solventar esa situación.
Aunque, en SQL server, si sientes que la integridad te afecta, puedes deshabilitar el check constraint, hacer las operaciones y habilitar el constraint, aunque no es nada recomendable, quizás si en ese insert es demorado es mejor validar con un DBA ya que para eso es la base de datos relacional y está optimizado para esas transacciones.
Un video maravilloso. Pero tube un problema SIMILAR. Teníamos una base de datos en SQL Sever con milles y miles de registros, aunque no llegaba al millon. Hizimos una replica de SNAPSHOT y todo funcionaba bien en local PERO cuando teniamos que inicializar la replica a traves de comunaciones, con un tunel privado sobre ADSL, la replica fallaba. No sabemos exactamente porqué. Supongo que las FK pendientes de verificar caducaban porque la conexion era lenta. Y la ÚNICA manera de solucionar el error fue elimar la FK.
En una empresa en la que trabajo no tenemos FK ni cascadas ya que trabajamos con una cantidad absurda de datos en varias tablas (chorros de millones para algunos clientes) y si usaríamos FKs y demás tendríamos muchos locks (lo sabemos por experiencia)
Si tienen locks no es problema de las fk sino de datos que rompen la integridad referencial y/o procesos de carga mal planificados. La fk funcionan perfectamente con miles de millones de registros y realizando consultas sql complejas. La velocidad dependerá, en estos casos, del tipo de base de datos (por ejemplo no es lo mismo un solo servidor con sql server on premises que un pool de servidores en azure synapse). Además debe configurarse correctamente la indexación, partición y distribución de las tablas, así como la optimización de queries complejos usando por ejemplo vistas materializadas en aquellos cálculos que son demandantes en tiempo pero repetitivos.
Me parece que dicha empresa no sabe lo que son las bases de datos analíticas, es muy raro que una base de datos tenga tantos millones y todos los datos se usen, por lo general solo un subconjunto se usa, y los demás son históricos, o puede ser que si se usen los datos y no saben particionar los datos en diferentes bases de datos.
@@christian.mar.garcia si era un proyecto con muchos problemas pero todos los datos se usan, si teniamos nuestro data lake y data warehouse para el data team
Algo que a muchos les puede dar problemas es cuando se usa un ORM y no se realizan los ajustes pertinentes... es que al consultar un registro que contiene muchas FK, el ORM puede traerse a memoria los datos completos de las tablas relacionadas afectando un poco el desempeño. Por esta razón muchas personas optan por no registrar como FK dichas relaciones y relacionar mediante esos campos únicamente cuando lo requieran.
Las FK son necesarias siempre cuando se quiera tener una estructura de datos ORDENADA. Para mantener datos históricos de servicios empresariales como utilities o banca, ciencia de datos, proyecciones, tratamiento de datos o interpretación de datos. Son necesarios según la envergadura y tipo de sistema. Aparte la idea es optimizar en base al volumen de datos, utilizar índices, etc, en mi caso trabajo con un proyecto de una empresa multinacional y las relaciones son necesarias, si se quiere conservar datos por regulación u otros motivos normativos caerás aqui en las bases de datos relacionales donde si o si tendrás que referenciar tus relaciones.
Yo aun soy un estudiante, así que puede que no tenga mucha idea de lo que digo... Pero personalmente a día de hoy, me da la impresión de que nos que prefieren no usar FKs deben ser familia de los que usan variables con dynamic,...
Si no usas FK, no eses db relacionales. Si no usas un sistema hibrido con los datos importantes en el RDB, teniendo en cuenta que un sistema de cache te puede ayudar con las GETs
Pos sería bueno una explicación de cómo o cuándo las FK no se deban usar... Las FK son la base de la integridad referencial, sin ellas, sería como preparar la sopa sin sal jeje
Hola, yo he enlazado tablas usando enteros como id y en las consultas enlazas con join, las bases de datos tiene mejor performance al ejecutar consultas complicadas
Pero eso sería una fk una id que se comunica con la otra tabla generando una relación en común y dependencia entre ellas, es eficiente ya que es una guía y el sistema no debe hacer la relación ya que está pre establecida
Hola, soy experto en ORMs, ¿por qué gastar espacio, el recurso más barato, cuando puedes obtener las ventajas de FK virtuales y curces de tablas en memoria en soluciones con sobreingeniería que ni se acercan a la eficiencia de las soluciones simples que llevan décadas entre nosotros?
En mi opinión es esencial tener una base relacional pero además bien hecha. Porque conozco programadores que hacen bases relacionales mal. Por ejemplo si una persona puede tener muchas direcciones, pero una dirección no debe pertenecer a varias personas, porque eso significa que si una persona cambia su dirección pues se cambia para todas. En este caso he visto cosas como: una tabla Persona, Dirección y PersonaDireccion. Donde el PK de Persona y Dirección se linkean. Cuando lo vi y lo comenté al programador su respuesta fue que él se asesora en el backend de que algo así no suceda. A lo que le respondi que me parece horroroso tener esa mentalidad. La base de datos y sus relaciones deben ser claras y no deben permitir que ciertas cosas sean posibles más allá del business logic. O sea son dos layers distintos. Yo viendo el layer a nivel base de datos diría que varias personas pueden tener la misma dirección y punto.
@@MarcosPic1982 Depende del caso. Si quieres mantener un histórico de direcciones es necesario hacer relacion varios a varios. La gente cambia de direccion y puede ocurrir que en momento x vivas en un sitio y en el momento x+1 viva otra persona. En las webs de compras suelen guardarte todas las dieccion que has tenido.
@albertosoto4280 no sé si te he entendido bien, pero creo yo, que a pesar de que las direcciones sean historicas, cuando una persona cambia de dirección y ahora otra persona se muda a esa dirección no se cambia el linkeo, sino que se vuelve a crear otra entrada similar o igual.
@@MarcosPic1982 Pero en la tabla de direcciones no puedes crear la misma direccion y asociarla a otra persona porque tendrias la misma direccion registrada con 2 PK diferentes.
En el proyecto en el que estoy actualmente tenemos que consumir un servicio hecho por otro team, no tienen ni una sola fk fuera de que hay una cantidad de relaciones. Simplemente cargan los ids, y listo... 😅
@joelgs4220 el tema es que el que nos supervisa a nosotros es un TL qué es frontend, y sumado a eso el otro equipo se maneja como super independiente cuando ellos en si nos sirven la data a nosotros, es super difícil tratar con ellos. Cabe destacar que muchas consultas o datos los niegan por una cuestión de performance, pero por detrás tenes cosas como estas. Usan también un orm y no cargan las entidades y sus relaciones usando lazy loading o eager loading, simplemente usan raw queries para todo y consultan usando los ids directamente o la conexión entre ids.
Eso se le considera una data base mal diseñada yo he tenido que hacer muchas veces rework de dichas db porque en sistemas pesados sin relaciones las query se demoran muchísimo
en un proyecto en donde estoy no usamos las foreign key, debido a que dependemos de 2 API externas que envian uno de los datos relacionados primero, uno antes que otro, por lo que tenemos por ejemplo productos antes que marcas y marcas antes que productos, por lo que no tenemos integridad en los datos, y hay queries de productos en donde no tienen marca en la otra tabla y se limpia la query antes de enviarla al front, una cosa muy rara
Hermano las bd son complejas y especializadas en gestionar datos la lógica en back no compensa esa velocidad pero hay puntos que entender 1 al modelar se puede priorizar entradas o salidas muchos ni piensan esto. 2 si tienes una tabla de 10M refactorízala según tu prioridad o particiónala o xxxx opciones que hay esto va de casos y no vale la pena decir solo uno 3 si usas uuid y no id int hay que entender que la forma de gestionar eso es distinto para la bd hay algoritmos de búsqueda que solo funcionan con id int ejemplo por ultimo no estoy seguro de esto que diré así que siéntanse libres de corregirme cuando la bd carga un SELECT con joins va filtrando a nivel de ficheros según los joins y luego cuando llega al WHERE eso se filtra en ram he visto SELECT que sobre cargan el WHERE con elementos que se deben filtrar en los joins y en definitiva al usar ORMs se olvidan del modelado 100%, me pregunto si modela por entidades o por las normas o por que criterio? es que sin saber eso es imposible saber si esta o no justificado el comentario
Y deje de estar pendiente de eso allá como en el 2006, Microsoft nos empezó a envagelizae que todo debe ser en procedimiento almacenado y vista , y empezamos todo a usar eso , después vino que ya no , que todo debe usar orm ( EF) que es mejor para quitarle carga de trabajo a la base de datos, luego que si los orm son pesado que usar dapper, ya cuando eso dije , me da igual, desarrollo lo que venga
Siempre que he trabajado con las FK en los sistemas que he desarrollado he validado que estos existan antes de hacer la inserción, pero también me he topado con sistemas que no hacen dicha validación y lo que muestran al usuario final es el error que te retorna la base de datos, mientras que en mi caso muestro un mensaje más claro para el usuario, aunque de cierta forma el usuario no debería de llegar a ese tipo de mensajes salvo que estén "jugando" con el aplicativo por lo que a veces me he cuestionado si es necesario ese tipo de validaciones para los usuarios "jueguetones". ¿Alguna sugerencia al respecto?
En teoría eso se maneja con un ExceptionHandler, has de cuenta que tu aplicación tiene un try catch, y el error de la base de datos lo transformas a algo que si sea legible, si la base de datos devuelve x error entonces en mi handler lo paso a tal cosa y devuelvo eso o le muestro eso a mi usuario. Asiendo eso en teoría no tienes que validar lo mismo que la base de datos y solo validas lógica de negocio.
@@MinombreesSergio lo que indicas es mostrar un mensaje de error genérico, aunque si no me equivoco en el try catch puedes especificar el tipo de error que estás capturando, supongo que con eso puedes mostrar mensajes más específicos.
@@alfonsobaqueiro creo que me faltó poner más contexto: el sistema no lo hice yo ni la empresa donde trabajo, lo heredamos cuando la compañía de seguros nos contrató para hacer mantenimiento a sus sistemas. Lo de la base de datos es una de las aberraciones que nos encontramos, otra, relacionada, era como abría conexiones de forma indiscriminada desde la app web, tumbando el servidor por falta de memoria. El código del sistema, sphaghetti puro y duro.
Si llegas a esa "masividad" de datos, el menor de tus problemas va a ser si tienes FK en la base de datos. Lo que te tendrá que preocupar es aprender a ser millonario.😂. Y créanme, en esos casos un programador no va a estar lidiando con esa parte de la infra, estará un DBA, arquitecto experto con su equipo para solucionar ese problema.
Imaginemos que tenemos una tabla usuario, y cada usuario puede comentar, dar like etc. Sin FK podriamos borrar el usuario, pero todos sus comentarios y likes etc.. quedarían en nuestra BD sin razón. Gracias a las FK y on delete cascade, si eliminamos un usuario se eliminará toda columna relacionada a éste.
De todas formas cuando hay 10 millones de registros, puedes usar caché. Y si eres muy bueno en bases de datos de vardad, como DBA, sysadmin... con Oracle, Postgres o SQL server, pues la cosa cambia drásticamente. ¿Cómo creen que hacen las grandes empresas que tienen bases de datos relacionales?. ¿Por qué migran de bases de datos nosql a relacionales?, de ésto hay varios casos bien documentados. Esto es tema viejo.
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
Mis Cursos de Programación: hdeleon.net/cursos-premium/
Mi Libro de C#: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/
Una FK ademas de relacionar las tablas ayuda al programador nuevo entender la relacion entre ellas, me explico el developer que sabe del negocio un dia X se va, se enferma, le ocurre algo, luego otro toma su lugar y no sabe del negocio las FK ayudan bastante a relacionar tablas y saber donde tocar y que manipular.
si tienes el código documentado no es necesario
@@christianalvarezsanchez8583 yo no tengo el codigo documentado y aun asi no las uso 😂
@@christianalvarezsanchez8583 casi nadie comenta las bases de datos
@@christianalvarezsanchez8583 pues en mi experiencia las bases de datos son poco documentadas, el código no tiene nada que ver con una base de datos porque usan modelos diferentes por esos existen los ORM.
Completamente de acuerdo. Yo entré a mi primer trabajo en una startup en la que había un único "desarrollador" PHP WordPress. De PHP ni él sabía qué era una clase.
Cuando le pregunté sobre cosas de WordPress, porque no sabía, me contó un popurrí de cosas que no entendí nada.
Abrí el DBeaver, vi el esquema de entidades, y al toque entendí cómo funcionaba todo. Desde ese momento pude empezar a desarrollar.
Las FK son esenciales para mantener la Integridad de los datos. Solo que debes saber hacer el diseño de la base de datos
El diseño de la base no me gusta :/
@@juancampos352 ¿por qué?,¿ no te gusta documentar? o ¿ te vas defrente al código?
@@AnthonyCode No lo tengo bien claro, recién empiezo en esto y es frustrante, estoy acostumbrado a hacer las cosas rápidas.
Me pasa lo mismo, estoy empezando y me cuesta eso
Iba a decir algo parecido a lo que dijiste... Si vas a quitar algo propio de una base de datos relacional, pues lo mejor sería no utilizar la relacional sino las otras opciones... pero ya decir que no tiene sentido como el del tweet... pues... se queda corto!!!
Estaría buenísimo ver las estrategias
Esperamos un nuevo video con las estrategias!
Gracias!
Las FK tienen su razón de ser... incluso para alguien nuevo que toma tu modelo de DB (sin diccionario de datos y sin nada más) para al menos entender la lógica/integridad de lo que has intentado hacer. No acepto que no las haya aun cuando sea un modelo básico de DB.
Dale hermano necesitamos estás estrategias. Jejeje saludos.
👍 por favor Sr. De Leon una explicación para esos casos donde la información es grande tanto para la persistencia y la lectura de los mismos, aprender tecnicas para las queries
Gracias
Apoyo el proximo video de alternativas a bases de datos relacionales y si se puede ser sobre alternativas open source mejor. Gracias Héctor por las reflexiones. Saludos a la comunidad!!
Si estaría excelente un video con las estrategias
Muy buen video :) si me gustaría ver que otras estrategias se pueden utilizar para cubrir esas desventajas. Gracias por el video Héctor
Buenisimo por las estrategias en las DB
Buenas!!
Muy informativo y claro como siempre!!
Estaría bueno así un mini curso o algo enseñando a como trabajar con sql y no-sql a la vez y como mencionas en el video, cuando es conveniente una implementación de ese tipo.
Gracias por subir toda esta enseñanza, siempre me sacan de algún lio 😅
Sí, sube video de las estrategias por fa
Excelente explicación!
seria bueno ver esas estrategias
Vi el tuit que relaciona a este video 😅 e increíble algunos le daban la razón.
Chingon , yo si quisiera que hablaras más sobre estos temas /,,/
la fk son básicas para la integridad de datos
Estaría bueno un vídeo sobre como manejar los logs en las bases de datos SQL 😌👌
Tecnicamente: cuando se agrega un FK se crea un contraint index, el cual se utilizara p validad la integridad. En varias Lectures de grandes empresas observaran que eliminaron los FK y utilizan la mezcla de bases de datos relacionales y NO relacionales por escalabilidad.
No soy experto, pero justo esto es a lo que se debió referir el tipo del tweet. Una cosa es la llave y otra el constraint. Se puede tener la llave sin el constraint
Estaba esperando este video con muchas ansias
En las empresas donde he trabajado no he necesitado eliminar FKs o usar nosql, las tablas que he manejado tienen algunos pocos millones y aunque si he enfrentado problemas de rendimiento no han sido causadas por las FK's sino por la arquitectura del frontend pero ese es otro tema...
Solo alguien que no sepa DB relacionales diría algo así, de cualquier forma el DBA debe diseñar un buen modelo de base de datos y protegerlos de las fallas de lógica en las aplicaciones.
Muchas gracias por compartir tus conocimientos, agradeceríamos más de uno que hagas el vídeo de las validaciones de fk, saludos 🤙🍻
eyyyyyyyy excelente este video, excelente iluminación... felicitaciones, excelente ver este video con buena luz, ahí le deje el pulgarcito arriba, saludos
El video sería genial 🎉
Justo pensé en las BD NoSQL, eso es básico del diseño y modelado de DB que antes de crear la DB debes pensar en que tipo de información vas guardar, si necesitas un orden estricto o mas flexible.
Estaría genial ver mas estrategias.
estaria excelente que nos compartieras esas estrategiiias!!! saludos
Vale, vale: pulgar arriba y sí, me gustaría ver un vídeo de estrategias para los sistemas de BD sin FK.😏
Grande Hector!! Aporto para el nuevo video! Gracias!
Tenes que hacer un video sobre composite Keys y sus problemas cuando el projecto escala, y los composite keys pueden pasar de ser solo 2 a 3 y a veces hasta 4, y lo que implica con el resto de las relaciones hacia esa tabla. Luego podrías hablar del concepto historization y tablas Master e History, y de cuáles son las ventajas del 1:1 vs el n:1. Son temas con los que los programadores se encuentran tarde o temprano y tienen que optar por una solución.
Si por favor
Estrategias si quiero conocerlas
me gustaria ver una continuacion del tema y que estrategias usar
Algo malo de internet es que permiten a gente que no tienen ni idea de un tema hablar de ello como si fueran expertos
Si nuevo video SALUDOS JEFE 🍺🤘🍺🎉🤓
Sería interesante ver ese vídeo con un ejemplo práctico de las estrategias de integridad sin FK, saludos.
Aporto pulgarcillo y me interesa saber mas
Crea el video de estrategias ya le di pulgarsillo 🤠
Excelente video
También puedes utilizar projections, creas una tabla única con todas las columnas necesarias, perp esta projection debe ser rellenada a partir de una query que consulte todos los datos que se necesitan de una DDBB relacional con FKs
Entonces las NoSQL es conveniente para datos masivos? Podrías dar un ejemplito sobre eso?
Excelente video!!
desde tu ejemplo cuando 1 referencia dentro de la tabla A hacia 1millon de la tabla B, Una estrategia podria ser crear 1 tabla C que sea que agrupe por zonas y con eso la base de datos seria menos estresada y conservando las Fk
Las FK ayudan a no repetir datos, reducen la cantidad de espacio requerido para almacenar la información, sirven como indices, y para los inserts no ralentizan tanto ya que exiten busquedas binarias en los índices. Se pueden desactivar cuando cargas datos masivos y sabes que los datos son integros y las activas una ves cargados, pero esa es tarea del DBA.
Hasta donde tengo entendido las FK a parte de dar integridad a los datos, estas generan un índice para hacer la búsquedas más rápidas y no tener problemas a la hora buscar información, no es correcto mencionar NoSQL cuando no está hecho para leer tanta información. Si no los bancos y grandes empresas tendría. Su data en estos tipos de BD. El tweet tal vez está enfocado a otro tipo de problemas que no es relacionado a esto, si no tienes bien hecha tu BD tendrás problemas de este tipo, muchas veces me tocó corregir consultas a la BD por qué no las hacían bien, ojo no soy DBA
Saludos cordiales
Héctor, a ver, si eliminas la foreing key y dejas que el backend maneje la integridad en la aplicación, el backend no tiene que hacer los mismo que SQL? Buscar en las 10M de marcas para ver si existe? Digo...
necesita mas videos asi. Del contexto no solo quemar a una persona por su opinion.
Que las fk son una carga? Que conviene usar NoSQL cuando hay más de 10 MM de registros? Bullshit! En big data se siguen utilizando fk sin ningún problema, en sistemas distribuídos modernos de datawarehouse las fk son básicas en el modelado multidimensional. La optimización de los tiempos de consulta se maneja por otras vías pero nunca, y repito NUNCA, eliminando las fk. El que posteó la eliminación de las fk no tiene mucha idea de como se maneja el tuning de bases de datos cuando se trabaja con big data.
Asi es.. traigan cervezas para este hombre..!!
¿Cuáles son esas alternativas?, porque no conozco tan a profundidad los motores sql, así sin investigar lo único que se me ocurre es tener una tabla intermedia que no use fk e irlas pasando poco a poco, pero seria mucho lio.
Puedes crear indices para campos por los que filtres frecuentemente en tus queries, puedes crear vistas materializadas para consultas o subconsultas complejas y/o frecuentes, puedes usar una base de datos distribuida para tener procesamiento y distribucion paralela de los datos y ajustar el particionamiento como la distribucion del cluster de nodos que conforman esa base de datos@@MinombreesSergio
Excelente video, esto es síntoma de usar siempre NoSQL y no tener [Ni p...] idea de DBs relacionales y como hacer una correcta normalización de las tablas, campos e índices, con esto ultimo se puede evitar o disminuir el caso explicado en el video.
dependiendo bro, en muchas soluciones no es necesario, por eso están las Nosql y entre otras porque en muchas ocaciones puedes manejarlo desde el código y la base de datos cuando las reglas de negocio son muy cambiantes solo necesitas donde persistir la data de forma lógica.
@@christianalvarezsanchez8583 No es una cuestión de necesidad, en algunos casos puede ser más conveniente utilizar una base de datos relacional y en otros no, depende mucho del contexto concreto del problema que se quiera modelar. Si va a trabajar con grandes volúmenes de datos y las relaciones entre las entidades no son tan marcadas, NoSql podría ser una excelente opción como bien lo explicó Héctor en el video, en caso contrario una base de datos relacional sería una una buena solución.
En este mundo no hay blancos o negros, existen matices que no se deben pasar por alto.
Hay ventajas y desventajas, no sean dogmáticos
@@christianalvarezsanchez8583 Obvio que NoSQL tiene sus aplicaciones, solo que en este caso, decir tal aberración sobre la FK, es un claro indicio de ignorancia supina.
@@GabrielGonzalez-kd9hf Bro en el desarrollo de software hay muchas formas de llegar a la solución, he visto empresas con grandes cantidades de tráfico que no usan fks y trabajan muy bien y escalan bien.
Me pregunto si cachear los datos de la tabla que contiene las FK sea una buena opción. y que la cache se pueda refrescar si hay un nuevo registro en esa tabla, de esta manera la validación de la integridad en la lógica podría ser más rápida. Es una idea jejeje.
Pero sí sería bueno que nos regalaras un video explicando como solventar esa situación.
Adelante con el video para alternativas para llaves foráneas.
Gran video Héctor. Gracias!
Me interesan las estrategias para asegurar la integridad sin FK. Gracias!
Aunque, en SQL server, si sientes que la integridad te afecta, puedes deshabilitar el check constraint, hacer las operaciones y habilitar el constraint, aunque no es nada recomendable, quizás si en ese insert es demorado es mejor validar con un DBA ya que para eso es la base de datos relacional y está optimizado para esas transacciones.
Siii porfaa
En mi MVP aplico las llaves foraneas, y si, es bastante problematico, sino sabes manejar el producto cartesiano, saludos cabezon.
Cuando usas Entity Framework ya se colocan las foreign keys. cierto?
Un video maravilloso. Pero tube un problema SIMILAR. Teníamos una base de datos en SQL Sever con milles y miles de registros, aunque no llegaba al millon. Hizimos una replica de SNAPSHOT y todo funcionaba bien en local PERO cuando teniamos que inicializar la replica a traves de comunaciones, con un tunel privado sobre ADSL, la replica fallaba. No sabemos exactamente porqué. Supongo que las FK pendientes de verificar caducaban porque la conexion era lenta. Y la ÚNICA manera de solucionar el error fue elimar la FK.
Ese mouse vertical es por sintomas o precaucion?. Pregunto por que un compa en la chamba tambien lo usa pero es por que si le fastidiaba
He visto muchos casos de muñecas jodidas
Hoy entregué un proyecto con oracle sql y sin las FK, no hubiera podido realizar mis consultas.
En una empresa en la que trabajo no tenemos FK ni cascadas ya que trabajamos con una cantidad absurda de datos en varias tablas (chorros de millones para algunos clientes) y si usaríamos FKs y demás tendríamos muchos locks (lo sabemos por experiencia)
Si tienen locks no es problema de las fk sino de datos que rompen la integridad referencial y/o procesos de carga mal planificados. La fk funcionan perfectamente con miles de millones de registros y realizando consultas sql complejas. La velocidad dependerá, en estos casos, del tipo de base de datos (por ejemplo no es lo mismo un solo servidor con sql server on premises que un pool de servidores en azure synapse). Además debe configurarse correctamente la indexación, partición y distribución de las tablas, así como la optimización de queries complejos usando por ejemplo vistas materializadas en aquellos cálculos que son demandantes en tiempo pero repetitivos.
Me parece que dicha empresa no sabe lo que son las bases de datos analíticas, es muy raro que una base de datos tenga tantos millones y todos los datos se usen, por lo general solo un subconjunto se usa, y los demás son históricos, o puede ser que si se usen los datos y no saben particionar los datos en diferentes bases de datos.
@@christian.mar.garcia si era un proyecto con muchos problemas pero todos los datos se usan, si teniamos nuestro data lake y data warehouse para el data team
Algo que a muchos les puede dar problemas es cuando se usa un ORM y no se realizan los ajustes pertinentes... es que al consultar un registro que contiene muchas FK, el ORM puede traerse a memoria los datos completos de las tablas relacionadas afectando un poco el desempeño. Por esta razón muchas personas optan por no registrar como FK dichas relaciones y relacionar mediante esos campos únicamente cuando lo requieran.
Las FK son necesarias siempre cuando se quiera tener una estructura de datos ORDENADA. Para mantener datos históricos de servicios empresariales como utilities o banca, ciencia de datos, proyecciones, tratamiento de datos o interpretación de datos. Son necesarios según la envergadura y tipo de sistema. Aparte la idea es optimizar en base al volumen de datos, utilizar índices, etc, en mi caso trabajo con un proyecto de una empresa multinacional y las relaciones son necesarias, si se quiere conservar datos por regulación u otros motivos normativos caerás aqui en las bases de datos relacionales donde si o si tendrás que referenciar tus relaciones.
He acá un hombre con cultura..
Yo aun soy un estudiante, así que puede que no tenga mucha idea de lo que digo... Pero personalmente a día de hoy, me da la impresión de que nos que prefieren no usar FKs deben ser familia de los que usan variables con dynamic,...
Si no usas FK, no eses db relacionales. Si no usas un sistema hibrido con los datos importantes en el RDB, teniendo en cuenta que un sistema de cache te puede ayudar con las GETs
La FK salvan trabajos, a mi me hizo un paro en un delete que no puse el where pero las FK me salvaron
3:08 lo escuché, ese gallito JAJAJAA
Una cosa es ser disruptivo y otra es decir m4m4das. Como siempre buen video mi Héctor!!
Pos sería bueno una explicación de cómo o cuándo las FK no se deban usar... Las FK son la base de la integridad referencial, sin ellas, sería como preparar la sopa sin sal jeje
Primer comentario 🤘
Hola, yo he enlazado tablas usando enteros como id y en las consultas enlazas con join, las bases de datos tiene mejor performance al ejecutar consultas complicadas
Pero eso sería una fk una id que se comunica con la otra tabla generando una relación en común y dependencia entre ellas, es eficiente ya que es una guía y el sistema no debe hacer la relación ya que está pre establecida
El creador del tweet es de esos programadores que luego borran la tabla brand porque se les olvidó el WHERE en el el DELETE
Hola, soy experto en ORMs, ¿por qué gastar espacio, el recurso más barato, cuando puedes obtener las ventajas de FK virtuales y curces de tablas en memoria en soluciones con sobreingeniería que ni se acercan a la eficiencia de las soluciones simples que llevan décadas entre nosotros?
En mi opinión es esencial tener una base relacional pero además bien hecha. Porque conozco programadores que hacen bases relacionales mal. Por ejemplo si una persona puede tener muchas direcciones, pero una dirección no debe pertenecer a varias personas, porque eso significa que si una persona cambia su dirección pues se cambia para todas. En este caso he visto cosas como: una tabla Persona, Dirección y PersonaDireccion. Donde el PK de Persona y Dirección se linkean. Cuando lo vi y lo comenté al programador su respuesta fue que él se asesora en el backend de que algo así no suceda. A lo que le respondi que me parece horroroso tener esa mentalidad. La base de datos y sus relaciones deben ser claras y no deben permitir que ciertas cosas sean posibles más allá del business logic. O sea son dos layers distintos. Yo viendo el layer a nivel base de datos diría que varias personas pueden tener la misma dirección y punto.
@@MarcosPic1982 Depende del caso. Si quieres mantener un histórico de direcciones es necesario hacer relacion varios a varios. La gente cambia de direccion y puede ocurrir que en momento x vivas en un sitio y en el momento x+1 viva otra persona. En las webs de compras suelen guardarte todas las dieccion que has tenido.
@albertosoto4280 no sé si te he entendido bien, pero creo yo, que a pesar de que las direcciones sean historicas, cuando una persona cambia de dirección y ahora otra persona se muda a esa dirección no se cambia el linkeo, sino que se vuelve a crear otra entrada similar o igual.
@@MarcosPic1982 Pero en la tabla de direcciones no puedes crear la misma direccion y asociarla a otra persona porque tendrias la misma direccion registrada con 2 PK diferentes.
@@albertosoto4280 cuál es el problema en tener dos direcciones iguales cada una asociada a una persona distinta?
Se desata uno de los jinetes del apocalipsis en una aplicación a gran escala cuando no aseguramos cosas en la DB
En el proyecto en el que estoy actualmente tenemos que consumir un servicio hecho por otro team, no tienen ni una sola fk fuera de que hay una cantidad de relaciones. Simplemente cargan los ids, y listo... 😅
en ese caso ¿ es posible que el supervisor de ambos teams le exiga al otro team que ponga FK a sus tablas?
@joelgs4220 el tema es que el que nos supervisa a nosotros es un TL qué es frontend, y sumado a eso el otro equipo se maneja como super independiente cuando ellos en si nos sirven la data a nosotros, es super difícil tratar con ellos. Cabe destacar que muchas consultas o datos los niegan por una cuestión de performance, pero por detrás tenes cosas como estas. Usan también un orm y no cargan las entidades y sus relaciones usando lazy loading o eager loading, simplemente usan raw queries para todo y consultan usando los ids directamente o la conexión entre ids.
Eso se le considera una data base mal diseñada yo he tenido que hacer muchas veces rework de dichas db porque en sistemas pesados sin relaciones las query se demoran muchísimo
Depende el caso, si se quiere una aplicación con consistencia eventual viene bien no tenerlas para que la aplicación sea flexible.
Y qué opinas sobre el uso de GUI como PKs en lugar de enteros???
Excelente estrategia para cuando tenemos dispositivos sin conexión, y más tarde hay que sincronizar
8:20 Sí, porfa, a más info mejor 🙏🙏🙏🙏🙏
has el otro video
en un proyecto en donde estoy no usamos las foreign key, debido a que dependemos de 2 API externas que envian uno de los datos relacionados primero, uno antes que otro, por lo que tenemos por ejemplo productos antes que marcas y marcas antes que productos, por lo que no tenemos integridad en los datos, y hay queries de productos en donde no tienen marca en la otra tabla y se limpia la query antes de enviarla al front, una cosa muy rara
Hermano las bd son complejas y especializadas en gestionar datos la lógica en back no compensa esa velocidad pero hay puntos que entender
1 al modelar se puede priorizar entradas o salidas muchos ni piensan esto.
2 si tienes una tabla de 10M refactorízala según tu prioridad o particiónala o xxxx opciones que hay esto va de casos y no vale la pena decir solo uno
3 si usas uuid y no id int hay que entender que la forma de gestionar eso es distinto para la bd hay algoritmos de búsqueda que solo funcionan con id int ejemplo
por ultimo no estoy seguro de esto que diré así que siéntanse libres de corregirme cuando la bd carga un SELECT con joins va filtrando a nivel de ficheros según los joins y luego cuando llega al WHERE eso se filtra en ram he visto SELECT que sobre cargan el WHERE con elementos que se deben filtrar en los joins y en definitiva al usar ORMs se olvidan del modelado 100%, me pregunto si modela por entidades o por las normas o por que criterio? es que sin saber eso es imposible saber si esta o no justificado el comentario
Querido Héctor se que no va con el tema del vídeo, al terminar tu curso dan algún tipo de certificación?
La de Udemy
Pulgar arriba
Acá aprendiendo conceptos. lml 666 lml
jajaja en la db de mi trabajo hay mas de 700 tablas imaginate controlar todo eso en la logica de la app
Las FK son básicas, si vas a relacionar registros de una tabla con otra, son imprescindibles para no tener datos huérfanos.
Y deje de estar pendiente de eso allá como en el 2006, Microsoft nos empezó a envagelizae que todo debe ser en procedimiento almacenado y vista , y empezamos todo a usar eso , después vino que ya no , que todo debe usar orm ( EF) que es mejor para quitarle carga de trabajo a la base de datos, luego que si los orm son pesado que usar dapper, ya cuando eso dije , me da igual, desarrollo lo que venga
Siempre que he trabajado con las FK en los sistemas que he desarrollado he validado que estos existan antes de hacer la inserción, pero también me he topado con sistemas que no hacen dicha validación y lo que muestran al usuario final es el error que te retorna la base de datos, mientras que en mi caso muestro un mensaje más claro para el usuario, aunque de cierta forma el usuario no debería de llegar a ese tipo de mensajes salvo que estén "jugando" con el aplicativo por lo que a veces me he cuestionado si es necesario ese tipo de validaciones para los usuarios "jueguetones". ¿Alguna sugerencia al respecto?
En teoría eso se maneja con un ExceptionHandler, has de cuenta que tu aplicación tiene un try catch, y el error de la base de datos lo transformas a algo que si sea legible, si la base de datos devuelve x error entonces en mi handler lo paso a tal cosa y devuelvo eso o le muestro eso a mi usuario.
Asiendo eso en teoría no tienes que validar lo mismo que la base de datos y solo validas lógica de negocio.
@@MinombreesSergio lo que indicas es mostrar un mensaje de error genérico, aunque si no me equivoco en el try catch puedes especificar el tipo de error que estás capturando, supongo que con eso puedes mostrar mensajes más específicos.
Quiero ver estrategia
Te lo digo en los comentarios ;-)
Yo estoy trabajando en un sistema (empresa de seguros internacional), donde los datos están en MySQL sin claves foráneas...
Pésimo
Estudia las formas normales y aplicalo
Si no te gustan las PK y FK, no uses bases relacionales usa las orientadas a documento Json como mongo db
@@alfonsobaqueiro creo que me faltó poner más contexto: el sistema no lo hice yo ni la empresa donde trabajo, lo heredamos cuando la compañía de seguros nos contrató para hacer mantenimiento a sus sistemas.
Lo de la base de datos es una de las aberraciones que nos encontramos, otra, relacionada, era como abría conexiones de forma indiscriminada desde la app web, tumbando el servidor por falta de memoria.
El código del sistema, sphaghetti puro y duro.
Y nunca cerraba las conexiones, por eso los problemas.
Integridad Refreencial y Normalización así de simple.
Si llegas a esa "masividad" de datos, el menor de tus problemas va a ser si tienes FK en la base de datos. Lo que te tendrá que preocupar es aprender a ser millonario.😂. Y créanme, en esos casos un programador no va a estar lidiando con esa parte de la infra, estará un DBA, arquitecto experto con su equipo para solucionar ese problema.
Imaginemos que tenemos una tabla usuario, y cada usuario puede comentar, dar like etc. Sin FK podriamos borrar el usuario, pero todos sus comentarios y likes etc.. quedarían en nuestra BD sin razón. Gracias a las FK y on delete cascade, si eliminamos un usuario se eliminará toda columna relacionada a éste.
De todas formas cuando hay 10 millones de registros, puedes usar caché. Y si eres muy bueno en bases de datos de vardad, como DBA, sysadmin... con Oracle, Postgres o SQL server, pues la cosa cambia drásticamente. ¿Cómo creen que hacen las grandes empresas que tienen bases de datos relacionales?. ¿Por qué migran de bases de datos nosql a relacionales?, de ésto hay varios casos bien documentados. Esto es tema viejo.
Es correcto... cervezas para este buen caballero!
igual mi profe me olbiga para mi trabajo parcial y final xdxdxddxdx