Para quienes estamos en el mundo de Base de datos (BD) y principalmente en SQL, es importante estar al tanto de las cosas que se están comentando van a suceder con nuestra plataforma de almacenamiento de información.
Independientemente de que tratamos de mantener nuestros desarrollos de la manera más estándar que se puede acercándonos a T-SQL, no podemos decir que esto es y será 100% eficiente, en algún momento podrán presentarse cambios en la versión de BD sobre la cual nuestro cliente está trabajando, bien sea por el sólo proceso de actualización, cambio de plataforma o adquisición por ser nuevo cliente, siempre deberemos estar preparados por las consecuencias.
En el artículo de "Dave does data" se pueden leer el "mundo de lo posible" o como dirían en principio de Peter, lo inesperadamente certero de acontecer, no es conveniente algunas practicas muy difundidas en el proceso de lectura de las BD con el "NOLOCK" / "READ UNCOMITED" dentro un "SELECT" o una consulta con leer de manera sucia o sin hacer bloqueo de datos, esto trae sus consecuencias y siempre deberá buscarse la mejor manera de hacerlo sin generar mayores problemas o datos e información errada.
Acá la solución, a mi manera de ver, debe ser racional y lo más controlada posible, toda vez que si no se aplican las mejores técnicas de lectura, también se puede caer en provocar mayor lentitud en las operaciones del servidor y en consecuencia usuarios muy molestos por los tiempos de respuesta, pero peor es tener un informe solicitado al sistema con resultados errados para una toma de decisiones, cualquiera sea el caso la consecuencia es muy delicada con la automática desconfianza sobre nuestros sistemas.
Al final en el artículo se muestran soluciones o ideas a aplicar para disminuir la posibilidad de fallas o errores, que es lo que obviamente estamos buscando:
SQL Server NOLOCK sugerencia y otras ideas pobres. - Dave tiene datos - Site Home - MSDN Blogs
También les sugiero leer
SET TRANSACTION ISOLATION LEVEL
No hay comentarios:
Publicar un comentario