¿Foreign Keys Lentos? Soluciones que te Aumentarán el Sueldo

[@hdeleonnet]

Mis Cursos de Programación: hdeleon.net/cursos-premium/ Mi Libro de C#: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/

[@soycmramos]

Ya decía yo que lo único que le faltaba a este canal y era una buena intro con guitarrazos bien pesados. ¡Gracias, Héctor!

[@seulflowstyle]

Considero que deberias seguir abordando mas temas sobre SQL, son muy utiles yo desconocia el particionamiento de tablas gracias, Saludos

[@wasa01234567899]

Genial, en este canal aprendo mucho, la manera clara y sencilla que tiene para explicar las cosas complejas me hace aprender fácilmente, ya tengo todos tus cursos, aprendí mucho porque vas directo al grano, pura información sin nada de relleno, como lo contrario a one piece

[@ReneContreras]

Excelente video, en mi caso la estrategia que usabamos para resolver este tipo de situaciones era mandar los datos inmutables a otra tabla y siempre se usaba solo la tabla original . Para los sistemas que necesitaban consultar los datos históricos usualmente usabamos una vista que era una union de las dos tablas anteriores. Como esas tablas contenian millones de registros nuestros sistemas de producción que solo usaban la tabla original funcioaban sin problemas de rendimiento.

[@hdeleonnet]

Me hizo recordar los snapshots en bases de datos.

[@jaimedfalla]

Excelente video. No sabía cuál era el uso de los árboles, bueno si, en IA y Maschine learning

[@mrdominguez]

Muy buen video viejo! Yo fui el que te cuestionó sobre el costo de las consultas en tu video pasado y que no se harían búsquedas secuenciales 😂 y tenés toda la razón, yo ya estaba asumiendo que se incluían índices en los FK y PK 😅 porque esa es la manera habitual y altamente recomendada de trabajar con BD relacionales, es como te enseñan a diseñar en los cursos de BD de la facultad y cuando usas un ORM también por defecto agrega los índices y constrains a los PK y FK priorizando las consultas, la integridad referencial y las buenas prácticas. Pero tenés razón, son cosas diferentes, se pueden crear FK y PK sin índices (que terminaría en búsquedas secuenciales en las consultas) o sin los constrains (que terminaría en una BD sin integridad referencial). No sé por qué hay gente que quiere hacer cosas raras, me quedo con tu frase "No sos Netflix, Amazon, Google, etc" 😂 ni siquiera esas empresas recurren a sacrificar los índices o los FK como "soluciones", escalan horizontal y/o verticalmente sus servidores porque tienen la plata del mundo. Nosotros los pobres podemos recurrir a hacer backups para despoblar la BD de registros muy antiguos o segmentar las tablas que tienen muchos registros y están ralentizando las operaciones como explicas en el video. Saludos

[@hdeleonnet]

La aclaración también fue ya que muchas personas no saben estos conceptos, y sirvió para aclararlo, gracias.

[@AlbertoMarun]

Estimado Hector, Gracias por estos excelentes video, necesitamos mas como estos.

[@Leonardo-s4t]

Saludos desde Perú crack 🤘🤟

[@viictimahs]

Que tal Héctor, excelente vídeo. Una pregunta, tienes vídeo sobre optimizaciones en SQL? Sobre índices etc ?

[@Lienherverd]

Excelente vídeo, saludos cordiales Héctor.

[@giovannisabogalcespedes1648]

Gracias por porfundizar en estos temas y ayudarnos a tomar consciencia de estos aspectos tenicos.

[@matiasmgm]

Buennaaa esa intro metaleraa

[@mishelrodri]

Grande Héctor! En mi antiguo trabajo solo usábamos índices ☠️☠️ jajaja y eran millones de registros creciendo exponencialmente en una base racional 🗿estás cosas ni las enseñan en la U y son tan importantes lol

[@luis9717]

Hola como estás Hector, buenos videos, puedes abordar sobre los deadlocked en sql server ?

[@rodolfotovartorres]

Muy buena explicación hector. Una curiosidad que he tenido es sobre el diseño de llaves primarias algunos utilizan enteros otros UUID o cadenas cual es la mejor forma de implementación o depende de tus reglas de negocio?. Saludos

[@SeekingAura]

@@rodolfotovartorres uuid te evitas el problema de tener que reiniciar los valores como pasa con el integer autoincremental, pero tiene el contra de que el lookup puede tomar más. Si no vas a buscar bajo esa llave primaria o no lo vas usar como FK podrías utilizar UUID en lugar de Integer especialmente si son muchos datos y que no importe la búsqueda. La estrategia que hagas para el cálculo del UUID debes tener cuidado ya que podría dar problema de integridad muchos insert seguidos

[@rodolfotovartorres]

@SeekingAura muchas gracias por aclarar mi duda

[@rbarriae]

Gracias por tu tiempo!! Saludos desde el sur de Chile. PD: ¿para cuando el curso de "MayaScript"? 😂😂

[@hdeleonnet]

🤣

[@Liumbert]

el 1000% guapo

[@MultiLinker]

Very good.

[@jairo_manrique]

Buen día. Entiendo que los índices funcionan en las consultas sobre la tabla en que se definen. Por tanto, el índice sobre la FK no ayuda en la busqueda sobre la tabla que tiene la PK. Algunos motores permiten definir el indice que se quiere usar en la consulta.

[@oscarreynar8904]

Pense que ibas a mencionar la estrategia de indices x metodo hashing, que ya de forma natural va ordenando el indice y que puede gestionar las colisiones porque el algoritmo repite la direccion fisica del registro en el indice. Ref. James Martin. Database Design.

[@sebastiansalazarguerrero1205]

Hola hector, me puedes compsrtir el video donde programas esa cache 😅

[@hdeleonnet]

kzbin.info/www/bejne/l4SukqiNedKWgNE

[@msnotif294]

Al menos en SQL Server se exige que la tabla destino de la relación tenga su clave primaria ya definida, la cual suele ser un "clustered index", bastante eficiente.

[@LuisEnriquePerezSira]

@@msnotif294 exacto, en lo personal uso el tipico FK a la PK de la otra tabla y ese PK como un identity (1,1), incluso son BIGINT (SQL Server) por el volumen de datos y hasta ahora es aceptable.

[@josephmoreno9733]

Pk o unique index

[@msnotif294]

@@josephmoreno9733 exacto, ambas cosas

[@AiMimi-Lunix]

Ahhhh para eso sirve la memoria cache!!!!

[@LuisEnriquePerezSira]

Recuerdo una tabla con 15 FK y el Merge de SQL Server se elevó exponencialmente (eso que eran PK a campos identity). Lo que hice fue a nivel de SP, la # (temporal local) garantizó la integridad de los datos y eliminé las 15 FK, el merge pasó de durar 15 minutos a sólo 45 segundos. ¿Piensan que fue la mejor forma?

[@davidvillamex]

No se qué es "SP", disculpa mi ignorancia, por eso no entendí bién que hiciste pero se ve que estuvo muy bién, Saludos 🙂

[@mariogomezarr]

@@davidvillamex SP es stored procedure, procedimiento almacenado.

[@davidvillamex]

@@mariogomezarr Gracias Mario, ahora sí entendí que pasó, Saludos

[@LuisEnriquePerezSira]

@davidvillamex mis disculpas. SP = Store Procedure. Procedimientos Almacenado

[@davidvillamex]

@@LuisEnriquePerezSira Gracias Luis, 👍🏻👍🏻👍🏻

[@cristiangno]

13:25 Si me tocó las buenas tablas tabla_2020, tabla_2021

[@jorgetorrelles1]

Se puede trabajar con indexedDB usando SQL para optimizar las busquedas o es un método inseguro?

[@hdeleonnet]

Es seguro en el 99.9999 de casos, lo que he grabado es para casos extremos, y a parte, fue algo que me pidieron grabar.

[@tarmagoyf95]

a ver, por norma general si tienes la fk apuntando a la pk de la otra tabla, de primeras si deberías de tener el índice, porque en muchos sgbd lo hacen así

[@hdeleonnet]

Que bueno

[@davidvillamex]

@@tarmagoyf95 , Gracias por el dato 👍🏻😃

[@nazgulresebo]

Nunca he entendido porque SQL Server no pone el índice de las FK por defecto.

[@faustinoolan9070]

Que pasa cuando un FK es string un Guid?, esto es peor?

[@wil-fri]

@@faustinoolan9070 GUID nunca debe ser un string, es un arreglo de bytes. Que se traduce a los valores hexadecimales que ves

[@ryfr1702]

Mmmmm ponle el índice ! 😅😅😅 las bases de datos gestionan muy bien y separas la tareas, la DB hace lo que mejor sabe hacer, para eso existen !

[@hdeleonnet]

Pues si

[@josephmoreno9733]

Pues es cosa de hacerle mantenimiento a los índices, que fragmentación, que paginacion, etc.

[@ryfr1702]

@@josephmoreno9733 claro, es una tarea que hay que hacerlo! Pero ponle el índice ! ✌🏼

[@josephmoreno9733]

@@ryfr1702 A eso me refiero. Ponen como problema el deterorioro natural de un índice por no realizar mantenimiento. Y en realidad no es ningun problema. Por otro lado eso no es obligación del desarrollador ese mantenimiento, es obligación del DBA incluso si el desarrollador puede hacer recomendaciones sobre el mantenimiento de dichos índices.

[@ryfr1702]

@ si eso no discuto ! Zapatero a tu zapato! Y no entremos en temas de desarrolladores vs DBA porque es un tema de muchas aristas !

[@elibubi004]

usas camstasia para hacer tus videos? que modernon papu

[@hdeleonnet]

Soy del siglo 21