Gracias por el video , mi sugerencia para el segundo error es que una cláusula de ordenamiento (ORDER BY) siempre va a ser costosa en cualquier base de datos y más cuando son miles de registros, para la consulta se podria cambiar por un MAX y y funciona igual de rápido que el JOIN , de hecho para miles de registro sería más rápida al solo responder a una peticion y no tener que resolver todas las coincidencias del JOIN para obtener la respuesta SELECT [User].name ,(SELECT DESC_LOG.descirption FROM (SELECT MAX([log].UserId),[log].desciption FROM [log] WHERE [log].UserId = [User].UserId GROUP BY [log].description) DESC_LOG )elUltimo FROM [User]
Justo estaba revisando si alguien comento esto , porque para mí esa sería la mejor solucion ya que no aporta una carga de escribir en la tabla user (ademas que es feo) Incluso lo escribiría de otra forma, con el join directamente y uana subquery para el where: SELECT MAX(LogId) FROM Log L WHERE L.UserId = U.UserId
en una empresa en la que trabaje me tope con el mismo problema, teníamos un sistema que era un reloj checador, registraba la entrada y salida del empleado y este sistema lo adquirio un cliente que tenia cientos empleados por lo tanto generaba cientos o miles de movimientos al día, y habia un modulo en reporte que era precisamente ver el ultimo movimiento de empleados y empezo a tardar mucho y la solucion que aplique fue precisamente esa, registraba el movimiento y con trigger actualizaba el campo del usuario
jaja que curioso me toco un problema similar al problema de Catalogos hace unos dias alguien implemento una relacion y estaba mal hecha y el dev estaba todo frustrado y atorado por 2 dias al final nos tomamos el tiempo de revisar y si estaba mal la relacion de entidades como comentas el man queria insertar un registro en una tabla donde el Id de la llave foreanea era inexistente en esa tabla. se reviso la relacion se hicieron los ajustes y listo. todo funciono de maravilla!
Veo un problema a la solución del problema del log: cabe la posibilidad de que cuando el triger quiera realizar el update la tabla Users(o el regístro específico) esté bloqueada. Creo que una solución con mejor performance sería añadir una tabla intermedia (siguiendo el patrón "una tabla, un uso") con solo dos campos: userId y lastLogId, de tal forma que el triger realice el update sobre dicha tabla (o la inserción si es el primer log). Muchas gracias por tus vídeos.
Ejecutar todo el script en lugar de la línea en especifico xD, lo bueno es que era de pruebas. Un compañero de trabajo DBA evita eso forzando un error al inicio del script para que si por error lo ejecuta todo, reviente el script al inicio y no pase nada.
Como siempre, excelente video hermano, gracias por tanto. Como punto de mejora, le sugiero evitar chuparse los dientes al dar su discurso en el video ya que se vuelve muy molesto al cabo de unos minutos y se roba la atención del oyente por ser tan repetitivo dicho sonido. Saludos!
Nada como hacer un delete sin where en producción! por suerte no fue difícil recuperar, eran datos sencillos A un compañero le pasó que hizo un drop cascade a la base de datos, eso sí fue épico!!!!
Un desgraciado el que le puso los nombres de las tablas. Si son dos catálogos diferentes, puede ser catalago_pantalones y catalogo_remeras por ejemplo.
Si te ha gustado el video me puedes apoyar dejando un pulgar arriba y compartirlo en tus redes sociales, ¡Muchas gracias!
Excelente video, mucha experiencia por compartir, saludos amigo.
Gracias por el video , mi sugerencia para el segundo error es que una cláusula de ordenamiento (ORDER BY) siempre va a ser costosa en cualquier base de datos y más cuando son miles de registros, para la consulta se podria cambiar por un MAX y y funciona igual de rápido que el JOIN , de hecho para miles de registro sería más rápida al solo responder a una peticion y no tener que resolver todas las coincidencias del JOIN para obtener la respuesta
SELECT [User].name
,(SELECT DESC_LOG.descirption
FROM (SELECT MAX([log].UserId),[log].desciption
FROM [log]
WHERE [log].UserId = [User].UserId
GROUP BY [log].description) DESC_LOG
)elUltimo
FROM [User]
Justo estaba revisando si alguien comento esto , porque para mí esa sería la mejor solucion ya que no aporta una carga de escribir en la tabla user (ademas que es feo) Incluso lo escribiría de otra forma, con el join directamente y uana subquery para el where: SELECT MAX(LogId) FROM Log L WHERE L.UserId = U.UserId
Muy buenas soluciones y tips, muchas gracias por compartir tu conocimiento y experiencia.
no he teniedo esos errores, pero sirve mucho ver tu experiencia !
Muy bien material como siempre, Héctor ! 🙌
🍺🤘
en una empresa en la que trabaje me tope con el mismo problema, teníamos un sistema que era un reloj checador, registraba la entrada y salida del empleado y este sistema lo adquirio un cliente que tenia cientos empleados por lo tanto generaba cientos o miles de movimientos al día, y habia un modulo en reporte que era precisamente ver el ultimo movimiento de empleados y empezo a tardar mucho y la solucion que aplique fue precisamente esa, registraba el movimiento y con trigger actualizaba el campo del usuario
Eso del order by es algo que yo también haría, gracias!
buen video, una cagada que me ocurrio fue en una query que usaban string sql fue quitar el exec en produccion vaya que dolio ese error XD
jaja que curioso me toco un problema similar al problema de Catalogos hace unos dias alguien implemento una relacion y estaba mal hecha y el dev estaba todo frustrado y atorado por 2 dias al final nos tomamos el tiempo de revisar y si estaba mal la relacion de entidades como comentas el man queria insertar un registro en una tabla donde el Id de la llave foreanea era inexistente en esa tabla. se reviso la relacion se hicieron los ajustes y listo. todo funciono de maravilla!
Veo un problema a la solución del problema del log: cabe la posibilidad de que cuando el triger quiera realizar el update la tabla Users(o el regístro específico) esté bloqueada. Creo que una solución con mejor performance sería añadir una tabla intermedia (siguiendo el patrón "una tabla, un uso") con solo dos campos: userId y lastLogId, de tal forma que el triger realice el update sobre dicha tabla (o la inserción si es el primer log).
Muchas gracias por tus vídeos.
Ejecutar todo el script en lugar de la línea en especifico xD, lo bueno es que era de pruebas. Un compañero de trabajo DBA evita eso forzando un error al inicio del script para que si por error lo ejecuta todo, reviente el script al inicio y no pase nada.
Como siempre, excelente video hermano, gracias por tanto. Como punto de mejora, le sugiero evitar chuparse los dientes al dar su discurso en el video ya que se vuelve muy molesto al cabo de unos minutos y se roba la atención del oyente por ser tan repetitivo dicho sonido. Saludos!
Ese nuevo campo "lastlogid" no desnormalizaría tu bd?
Como solucionarias el reporte si desnormalizar?
@@hdeleonnet puede que con la tupla de indices en logs (id_user, id_log)
Nada como hacer un delete sin where en producción! por suerte no fue difícil recuperar, eran datos sencillos
A un compañero le pasó que hizo un drop cascade a la base de datos, eso sí fue épico!!!!
Un desgraciado el que le puso los nombres de las tablas. Si son dos catálogos diferentes, puede ser catalago_pantalones y catalogo_remeras por ejemplo.
Esos errores son muy sencillos o me he enfrentado a peores
Jaja el delete sin where, a mí me pasó con un update :'(
aprendes mas cuando uno la caga *("cometer un error")
th-cam.com/video/i_cVJgIz_Cs/w-d-xo.html esa cancion es ad-hoc